As with anything done for the first time, this also came along with a lot of learnings. I decided to write this blog post for reflecting on our learnings and share with others launching on Producthunt for the first time.
Setting expectations right in the beginning
We started to discuss the idea of building this product June 1st, exactly 24 days before the launch. We wanted this to be a project with a clear focus and expectations so we put down our notes in a simple Google Doc. Normally we use Clubhouse.io for project management but this time it was only two of us working on the project and we decided to keep things simple and stick to that document for both pre and post launch task.
After an hour of brainstorming around the product idea, we sat down and wrote our expectations from this project. Since StockHound is not intended to be our main product, we had to be careful with the effort that goes into this project. We decided to draw the lines clearly so we don’t over engineer anything which may not generate a significant business value. We were particularly careful about this because we know how excited we get when we are building and shipping new products 🚀 If you are a product person, you know the fallacy I am talking about ;)
We defined our goals around the following points:
- Number of leads generated on the launch day
- Number of meaningful conversations with users from our target segment
- Validation of launching a micro app as an organic acquisition channel
Working backwards, the press release approach
You may have heard about the working backwards approach from Amazon. We try to follow this approach as much as we can do in our product management procedures at Fabrikatör. We particularly love this because
… if the teams can’t tell a compelling story about the product, the problem it solves and how it succeeded in terms that could be published in a newspaper and understood by the majority of the public, then the concepts they’re considering are too complicated.Source: Jeff Gothelf’s post
Both of us wrote our own version of the press release explaining the problem, solution and why someone would need our product. We compared both versions, cross checked and criticised each others press releases. In the end we combined them and finalised the borders of the project. This immensely helped us in aligning expectations within the team and also made it easy to work independently on our tasks without communicating with each other on smaller details.
One of the first drafts which later on helped us to write the real PH launch notes:
Breaking down tasks and responsibilities
We created three buckets for the tasks which will help us reaching our launch goals:
- Marketing: Brand, messaging, creative content, logo, domain etc.
- Communication: Channels to share the launch, communities to get feedback from, template messages to be sent on each channel
- Product – tech: Anything related to the product we are building including the software development and UX
We split these buckets between us; I took the marketing and communication while Demirhan led the product-tech side of it until the launch day.
Here are some of the tasks that we placed in these buckets.
- Setup a new domain: Make it easy to remember and relevant. After coming up with couple of alternatives I shared them with my international friends. The most useful feedback came from the native English speakers and they saved us from launching with a brand name which might have some weird connotations that we could have never thought of 🙃 (~ 1 hour)
- Design a landing page: Keep it simple and useful, no need for CMS or anything fancy. We used a static HTML page and focused on the content. Again I took 2-3 rounds of feedback by sharing with native speaking friends and iterated the design & content. Here’s the result. (~3-4 hours)
- Design a logo: If you are unsure about your design skills or if it will take you too long to make one, you should ask someone from Fiverr or try a tool like Hipster Logo Generator. I designed our logo on Figma because I enjoy playing around with visuals (~ 1 hour)
- Design an animated GIF: This is not essential but it makes your listing more catchy on PH. I haven’t designed animations since 2010 I guess so this was an interesting opportunity to brush up my skills. After watching a couple of tutorials on YouTube, I designed our GIF on Figma with the help of Figmotion plugin. Alternatively you can also consider working with GifGiv who is specialised in preparing PH launch visuals. (~ 2 hour)
- Define a colour scheme: This may seem like a small detail but defining the colour scheme in advance will save a lot of time at every bit of your launch preparation.
- Design a hero image: Describing the product at the simplest level possible. A random person walking on your street should be able to understand what you do. I designed ours on Figma and to be honest it was challenging to simplify the product idea down to a single image. I still believe it is not perfectly simplified but it does the job. You can check it here. (~ 2-3 hours)
- Set up email templates
- Find a hunter: In my opinion this is not as important as you it is advertised. You can always hunt your own product instead of spending time and $$$ on PH hunters. We worked with Chris Messina and mainly because offers a clear documentation about his process and he pretty much automated the whole process which takes out all the unnecessary communication. We didn’t pay Chris for this hunt so my experience is based on his free offer. I think building up your own audience and launching with a strong communication strategy is 10x more important than you who is hunting your product.
- List the relevant networks and channels to announce our product. Communities on Slack, WhatsApp, Telegram, Reddit, LinkedIn & Facebook groups, forum boards
- Prepare the message text for each distribution channel in advance, don’t get busy with those on the launch day
- Write the contents to be shared on the launch day
- We focused on a single problem to solve and limited our product focus on that specific problem. We did not go for an extra mile to make things pixel perfect or aesthetic. In my opinion we did a great job repurposing one of our existing features and turning it into a free product.
- This part was mostly technical so I leave it to Demirhan if he decides to write about his experience :)
What we have learned?
We did a post launch analysis and did a brief retrospective on our learnings from this launch. I would like to share the ones may help you as well:
Fact: In terms of traffic, our post on Reddit brought more traffic and qualified leads compared to the PH launch.
Learning: PH is huge and the interests of the audience is so broad. Since our product was targeting Shopify store owners who manage physical inventory and afraid of running out of stock; our target was difficult to be found on PH. On the other hand, r/Shopify subreddit was a bang on because that’s where our users hangout, seek help and engage with the content. If you are releasing a very niche product which can be appreciated by a very specific segment, channel your energy in finding the places your segment hangs out instead of spray shooting on PH.
Fact: You can only control your own PH launch. The uncontrolled factors are the ones that impacts your success on the launch day.
Learning: If one of the big companies get listed on your launch day, your chances are way less to be in the top 3. Windows 11 was announced on our launch day and dominated the top section for a while.
Misconception: PH algorithm will penalise you if people find your product through a direct URL.
Fact: “Link directly to your product page. Linking to “producthunt.com” only makes it harder for people to find you and doesn’t have any effect on the algorithm at all. It seems to be “common knowledge” that you’re punished for linking directly to your product page — it’s simply not true. Focus on communicating what your product does. P.S. Linking to producthunt.com is one of the clearest indications you may be “over-optimizing” your launch (gaming the system).”Source: Official post of PH
PH launch should not be the final destination, it should be a jump start of something bigger. After the launch day, look back at the content and materials you created. Go through the reviews and extract the useful information out for improving your messaging and product. Re-use the materials for reaching out to your users through different channels. Run small budget ad campaigns to test, write blog posts and share with the world. Use this investment you made as much as you can.
I hope this comes useful for people who are launching on PH for the first time. There are so many things to share and I could not decide on what to include in this post. If you have further questions, feel free to drop a comment and reach out to me on Twitter & LinkedIn.
It was around 2012 when the term “squad” started to be more popular among startups and product people. It was mostly remembered with “Spotify” since they are the first ones who openly shared their own squad setup with the industry. Nowadays, even after 7 years, it is still a popular framework for building product-centric organisations.
I was lucky to be a witness of this transformation phase at ING and then leading discussions on this matter at one of the fintechs I worked as a manager. During these experiences, I learned much from other people and also self-educated myself while looking for the best practices to apply this framework into our own organisation. I ended up creating a pretty helpful list including some crucial changes to be made in both engineering and product teams. The list was sitting in my notes for months and today I decided to share it with others who may find it helpful!
What you should expect from this article?
If you are already on-boarded on the idea of squad framework then this article will provide you more insights about tech and process implications of it. If you are new to this framework then you will find many references to other articles which will help you to onboard yourself.
Mostly organisational changes are often slow, difficult and complex. Therefore it is not possible to cover every and each aspect, so I will be briefly touching the critical points and give you some kind of an index to follow if you are considering rebuilding your product organisation.
Software and Product Development
Squads are built for having small but effective product teams who are autonomous when it comes to ideating, building and releasing work. Splitting teams in different islands and giving them a cool work space is not enough for benefiting from squad framework because these teams needs to be backed up by supporting processes from tech side as well!
Release processes: Freedom of having independent releases are very important for squads. Squads having dependencies on each others releases will kill the velocity expected from the framework. If you haven’t already considered continuous delivery and continuous integration, I suggest adding these to your reading list among with microservice architecture because adopting these will help you a lot on switching to squad-based independent releases.
In an ideal world where you are running your product on a microservice architecture you will be able to give ownership of each service to one squad who will responsible of the CI/CD and maintenance of that particular service. A squad should be able to define their own release process and set it up in the most efficient way for their work routine.
Although having separate release procedures for each squad, you should always keep communication tight between each of them before and after releases in order not to create chaos! Using asynchronous communication methods might be the answer for distributed teams.
Having independent and autonomous squads should not weaken the communication between each other!Bahadır Efeoğlu
In order to have independent backlogs and not conflicting work in each squad you have to decouple your release processes for each squad. Squads are there for creating small, autonomous task forces which will give you agility and independence.
Backlog and sprints: Therefore each squad should own their own sprint boards and sprints. This means that, squad members defines their sprint goal and commit to that goal. If you have split your squads based on business KPIs such as acquisition, retention and innovation then each squad’s sprint goal should be aligned with related business KPIs.
Sprint goals serving to business KPIs will definitely change the way you measure success in sprints. A well decided sprint goal will be a more powerful instrument than sprint velocity for measuring success.
This will give more ownership and in depth business understanding to engineers who are mostly not very well into those by choice or by the nature of the organisation.
In the part #2, I will be covering how to defeat knowledge silos, how to utilise feature toggles and how to deal with ad-hoc tech support requests – yikes!-
Let me know in the comments if you ever tried one of those, what worked and not worked in your case!