Friday, September 22, 2017

Finding Insights To Grow Your App

If you’re trying to reach a particular milestone with your product, you’re constantly asking yourself what you should be working on next, and whether the things you’re already working on are even worth it. You’re continuously coming up with ideas, but which ones need to be prioritised first, and how would you even go about estimating their priority?

By the end of this, you’ll be equipped to begin answering those questions yourself and know where to investigate further. I’ll share techniques, examples and illustrative real stories to explain.

What Does The Data Say?

Because we’re working on software platforms, naturally one of the tools in your arsenal is all of the data you’ve managed to collect on user behaviour. Looking through this behaviour to find correlations and insights to help improve user experience is a great place to start.

For example, if you’ve got an ecommerce store you might find that when users view the product page more than one time they are more likely to make the purchase. So if you’re trying to increase the number of purchases, you should focus on making it easier for users to return to the page. This could mean directing those particular users back to the product page within the app, sending notifications or emails.

If you haven’t heard of pirate metrics before, I suggest you flip through Dave McClure’s slides. The idea is that you can segment your levers of growth - Acquisition, Activation, Retention, Referral, Revenue or AARRR for short. Using the pirate metrics is a universal framework that growth teams use to abstract our different insights, and also what the goal of new features should achieve.

Following on from the previous e-commerce example, arguably we’ve found a correlation between an activation metric (users viewing the product page more than once) which will have an impact on our revenue (purchasing the product). Our hypothesis therefore is that if we pull this activation lever more, we’ll increase revenue too.

Talk To Your Users

If you’re constantly only running A/B tests without thinking about a longer term vision, it’s easy to move towards local maximums, instead of the bigger global maximums of growth. This may sound simple, however it’s an easy trap to fall into and I’ve witnessed this happening first hand. To overcome this, you’ll need to really understand your users and have a long roadmap. User feedback is especially important if you're a new startup and only have a handful of users.

As Paul Graham (startup wiz, partner at YC) says, this will be your only chance to talk to your whole user base at once and build a product that just for them. This is exactly the advice that Brian Chesky took to heart we he founded AirBnB. He moved from Silicon Valley to New York because that's where all of his early users were, and literally slept on their couches to get feedback from them.

If you’re looking for direct feedback on users using your product and UI/UX works, my favourite tool is Alternatively you can run surveys on your site. A more structured and widely used way of collecting feedback via surveys is the net promoter score (NPS). Transferwise, an app that gives people a cheaper way to send money overseas, uses NPS as one of their main KPIs for new releases. I was able to catch Transferwise VP, Growth Nilan Peiris talk at the 2017 Growth Hackers Conference in Los Angeles. During the talk, he explained how Transferwise uses NPS. Check out his slides to learn more about how they use it.

The easiest, cheapest and free way to get feedback is to just get face to face with your users (or sleep on their couches like the AirBnB founders). The tricky part with getting qualitative feedback is knowing what questions to ask and how to ask them without biasing the results. User feedback is harder to analyse vs. data driven quantitative analysis however it can be done. You’ll need to spend the time and effort going through the feedback, estimating their impacts quantitatively and prioritising them accordingly.
Find Inspiration Around You
Another great place to look for things to test is to get inspiration from other products you admire for whatever reason. The saying “Good artists copy, great artists steal” really does apply here. You can’t just blatantly copy, it won’t work. You must first understand the mechanics at play, and carefully work out how you can implement the same mechanics on your product. Great examples are everywhere like Uber’s “Refer a friend and you’ll both get $20 of free rides” to something as simple as Pinterest’s famous unlimited scrolling feed. You should always be on the lookout for great products and think about how you’d like to improve them and your own product. They don’t always have to be from the big names in the game, a lot of smaller startups have some cool new ways of doing things.

One of the most awesome things about the team I’ve been lucky enough to work with is that we’re all coming up with ideas together. It’s your responsibility to ensure your team feels like they are in a safe environment to be able to contribute to ideas. Even if your team is ready and willing to contribute to ideas, are you giving them the ability to do so meaningfully? That is, do they have access to the same tools, dashboards and data as you do? Without this, don’t expect great contributions. You’ll also need to make sure these contributions can be recorded by the team easily.

Don’t be afraid to add a bit of fun gamification to increase the level of adoption in your team. Something as simple as a leaderboard for bragging rights, or free coffees for the top contributor achieves what you need. Don’t make the mistake of underestimating this valuable feedback from your team, in my experience some of the best ideas come from them. It also has the side effect of making your team a fun team to be in.

Prioritising Your Ideas

No matter how big or small your company, whether you’re Bill Gates or not - there’s one important resource that everyone has in the same quantity. If you haven’t guessed what it is already, I’m talking about time. For your business this means you only have so much runway before your plane has to take off. You’ll come up with thousands (if not more) ideas of things to do next, the life or death scenario is which do you focus on first? There’s no easy answer here, but having a logical framework to follow really helps make the right decisions more often than not.

One of my favourite ways of prioritisation is using ‘ICE scores’. It stands for Impact, Confidence and Ease. Using ICE scores helps you avoid embarking on features that have a huge amount of impact, but require months to build when you could be focusing on something else which provides the same impact and can be done within days. Don’t forget to be as data driven as you can during this process - the data doesn’t lie.

If you’d like to learn more about the framework itself check out this help article on Growth Hackers. Sidenote, Growth Hackers actually has a nifty tool I’ve previously used for helping me prioritise your tests with the ICE framework.

ICE is a great framework because of its simplicity. More likely than not, you’ll be working on your project in a team. It’s important your decision making process is logical as well as easily digestible by your team. If it’s not it won’t be adopted and people will revert back to their ways. I’ve seen this happen countless times when managers try and implement unnecessarily complex processes and adoption rates suffer because of it. It’s always a tradeoff between adoption rate vs. robustness and is something to be aware of.


The whole ideation and prioritisation process should be a repetitive cycle that is continuously and consciously happening within your team. Make sure you have a balance between quantitative and qualitative approaches, or you’ll end up focusing on the wrong things if you’re too extreme in either. You’ll have thousands of ideas you want to test, prioritising them can separate the failures from successes. Building great products is a team sport. Don’t underestimate this, and always consider their adoption when implementing or changing processes. You’ll be a bad manager if you don’t. Hopefully you’ve got a few ideas you can apply straight away. I could (and will) write a lot more on each topic covered, however my intention in this post is to provide an overview so you know what to learn next.

Friday, September 15, 2017

What does being the CEO of your Product really mean?

I was recently invited to a panel discussion at UNSW to discuss Product Management and answer any questions for students looking for more information about it. The discussion throughout the night reaffirmed my thinking that each Product Manager role at a company is going to be vastly different. The topic of being the CEO of your product came up and to my surprise, quite the majority of the panel disagreed with the analogy. I think the analogy has some flaws, however it does hold some truth to it.

Before explaining why I love this analogy and use it as a great example, I will explain what I think the main flaw in this analogy is. To put it simply, calling oneself the ‘CEO of a team’ sounds downright egotistical and condescending in nature to anyone without proper context. This has nothing to do with what it really should mean.

One of the reasons I love my job (and sometimes the cause of sleepless nights and stress) is that you as a PM are accountable for everything that happens in your team. This starts with being accountable for ensuring your team hits their quarterly targets and releases, and leads into ensuring the working environment and team is really set-up to achieve them. If your team doesn’t meet targets, guess who people start looking for? Not the engineering team lead, or the designers, it’s the PM. Accountability is what gold standard CEO’s live by, and it’s an important quality of a PM.

In most cases a Product Manager role is a ‘do whatever it takes to get things done’ kind of role. It’s exactly what a CEO’s job description is. To give some context to this, I’ll share a personal story from the trenches. We had a release which was due to be shipped a month before the quarter end, and had a reasonable revenue target by the end of the quarter. Reasonable that is, if you assume it shipped on time and not 3 days before the quarter end. With only 3 days, we had to act fast. We got a list of customers that based on their past behaviour, would be highly likely to be interested in purchasing our new product. I spent the next 3 days personally selling via our onsite chat system until midnight of the last day of the quarter. The funniest part of the story is that we missed our target by only 1 sale - if I wasn’t so busy selling, I would have put my own credit card in! The point of the story is that becoming a direct sales person isn’t what most people have in mind when they think Product Manager. It’s the PM’s duty to do whatever it takes, no matter what they need to do to (ethically of course), to get things done. Sounds a bit like a stereotypical scrappy startup CEO to me.

To conclude, it’s not a perfect analogy, as some people may misunderstand what this means and take it a bit too far. I think this misunderstanding and egotistical behaviour is why the majority of people don’t like the phrase anymore. With this mindset, it’s a great phrase to use when explaining just how accountable you really need to be when you take on the role.

A Panel on Product Management

A Product Management Panel with Atlassian, Canva, Freelancer, Pivotal Labs and ProductRise hosted by UNSW, Australia.