Although I’m fundamentally a technologist, I have long believed that the only purpose of writing software is to build great products for your users. I’ve worked with some of the very best product managers in the industry. I’ve even been a product manager a couple of times myself.
Here are some tools you can use when developing products, especially if you work in a product-focused startup.
How do you measure your product’s success? If you don’t measure the right things, you can never make the product better. The best framework for startup product metrics is Pirate Metrics — its called that because the acronym is AARRR, matey. The pirate metrics tell you what things to measure about your product.
- Acquisition: how do users find your product, maybe through search, ads or referral from a friend. These are often called channels e.g. SEO, Word of Mouth, Google Adwords etc
- Activation: measures how you turn a first time user into a repeat user. You can be great at acquiring users, but if you can’t get them to come back to your product, all that work is for nought. For a long time, Twitter had a serious activation problem: millions of people have tried Twitter, but only a small percentage have become regular users because the value of the product isn’t obvious to them. A product can be extremely useful, but if it doesn’t get a user to that useful experience fast enough, they will give up on it.
- Retention: do users keep coming back to your product in the long term, or do they gradually give up using it? Good retention is partly a function of how good the product is, and partly a function of activation.
- Referral: getting one happy, retained user to refer another person to the product. Also known as viral marketing. This can be an extremely powerful way of getting new, high quality users because a recommendation from someone you know is much more likely to get you to try something than an ad or a Google search result.
- Revenue: how much revenue you earn from your happily retained users. This is the ultimate measure of success for a product and a company.
The aha moment
When you’re building a product, find the aha moment for new users. This is when a user realises the full power and value of your product. This often happens when people are using the product and it suddenly does something “magic” for them.
Google Now can deliver great aha moments. It is a phenomenally complex technology, and its hard to explain what it does. I had it installed on my phone for some time but didn’t use it much. Over time, it figured out where my office and home were, and one day told me there my train home was delayed. I hadn’t done anything to tell it about my commute, it just popped up incredibly relevant and timely information. A real “oh, now I get it” moment for me.
Spend time watching how people use your product. Figure out what the “aha, now I get it” moment is for them. Then ruthlessly optimise the software to get new users to that moment as quickly as possible. The aha moment is when fleeting visitors convert into people who love your product and use it every day.
The 80:20 rule
When you are building a startup, perfectionism is your enemy. You have a small team, limited resources and you are battling against the clock to find the product that works.
There is an interesting rule of thumb that 80% of the value of a product takes 20% of the overall effort to build. The other 20% of the value takes the remaining 80% of the time. This applies to a wide range of activities: 80% of sales often come from 20% of customers (because a few large customers are disproportionally more valuable than the many small ones) and Microsoft discovered that fixing the top 20% of bugs eliminated 80% of the reported crashes.
Your job as a product manager is to identify the 20% of the effort that will unlock 80% of the value and stop before you hit diminishing returns.
Minimum Viable Product
A key principle of modern product development is to build the Minimum Viable Product. As a startup, your one advantage is you can move fast. The people building startups are not like their users; if your startup team is 20 people and you’ve got 10 million users, by definition your team members are atypical. So you need to learn what works for your users as quickly and efficiently as possible and not rely on your intuition for what they need.
Focus on answering questions, not building products. What is the smallest thing you can build and release to users that will help you learn more about what your users actually want? The answers you get will surprise you and confound your intuition.
Be creative. Do you need to build an application at all in order to find out what users want? Could you show them a paper prototype that is cheap and easy to build and will quickly let you know if you are on the right track? Can you add a rough and ready version of a new feature that helps you learn?
At Songkick we wanted to know if people would share concerts with their friends. We could have spent a couple of weeks building a fully featured social media tool that integrated with Facebook, Twitter, Google+, LinkedIn and Instagram. We would integrate each service’s API with our internal User and Concert models, with scalable code and beautiful graphics.
We didn’t do that. We took a screenshot of a Facebook button (about 3 minutes), slapped it on the concert page (another 5 minutes) and then wired it up so when users clicked on the button it added one to a counter in our logging system (10 minutes). In less than 25 minutes we had built and deployed this. Within a day we could tell what percentage of people visiting a concert page wanted to use a Facebook share button. The cost of building this was tiny, but the value of what we learned was huge.
Always find the smallest possible product that will allow you to learn from your users.
Discovery vs Delivery
Product development has two distinct modes:
- Product discovery — figuring out what people want. Which features do users love, which don’t they need. In this mode, ruthlessly apply the MVP approach, running lots of fast, cheap experiments. The only aim is to learn what users want. Expect 80% of your experiments to fail. The faster you move to the next experiments, the faster you find what works.
- Product delivery. Once you have found what works, throw away the experiment and build it properly from scratch. Craft the design and the code so that it is beautiful and long lasting. This mode is all about quality and care. Build it as well as you know how.
Make these two modes as different as possible and be very explicit about which mode a product team is in. As product manager you get to declare: we have finished learning about this feature, now let’s start over and build it right.
Design vs Experiment
There is a tension between discovery and delivery. MVP features can appear rough, even broken to users — the “fake” Facebook share button I mentioned above looked like a bug to the people who clicked on it because nothing happened.
Your brand is important, especially once you start to grow. Your product is the core of your brand. Running too many experiments can leave users frustrated and feeling like you don’t care about quality. A rough user experience can hurt your activation, retention, referral and revenue metrics.
There are ways to maintain visual and UX consistency even while running multiple MVP experiments. A strong design library can provide tools for fast, brand-aware experiments. Make sure you are as good at product delivery as you are at product discovery. Ensure you have space to properly design the user experience for the long-lived parts of your website.
A product management toolkit
These are some tools I like for product development, in the broadest sense. Great product management is a blend of design, technology, and product thinking. Find the mix of tools that work for your startup and your products. Hopefully some of the above will be useful for you.