How to know what to build next as a Product Manager

How do you know what to build next? If even the best plans can fail, how do you improve your chances of success? In short, you just need to try more things.

We all know what you shouldn’t do:

• Spend weeks or months agonizing over what to build

• Spend months building something without getting feedback

• Launch the thing to find out it’s not what anyone wanted in the first place

So, how do you know what to build? If even the best plans can fail, how do you improve your chances of success? In short, you just need to try more things.

I’ve recently been re-inspired by Facebook’s testing philosophy. Years ago, Boz (Andrew Bosworth) wrote about it on their engineering blog. I read about it then and later heard about this rapid testing process from other companies like Netflix and Amazon. I’ve worked hard to implement this at several companies and on a few projects. It can be a difficult transition, and creating the safety to do this can require a massive culture shift.

But good products aren’t built in a vacuum. The feature you think will be impactful could completely miss the mark. That thing everyone is convinced will never work; it may just be your golden ticket.

I’ve tried to drive this culture of testing wherever I’ve worked. When I was the Head of Product at a small tech startup, pushing us in this direction was easy because I didn’t have to convince many people. In larger, more established companies, it’s been far more challenging, especially without the same level of seniority.

Many businesses think they’re adopting a culture of rapid testing, but they’re a long way off. Sometimes, it’s because they’ve never really seen what’s possible. Maybe you’re in a similar situation. Your company may be content with launching new experiments every few weeks or months and think this is top speed. They don’t realize it’s possible, and maybe even essential, to launch several experiments per day.

This doesn’t apply to every feature. It might be hard to get a test out today for a new login integration or a new self-serve cancellation flow. However, there are still ways to test those things and get real-world data today through concepts like pretotyping. See Alberto Savoi’s resource from his book, The Right It.

However, if you manage a user funnel, you should definitely test everything you can. That applies to marketing, SEO, and sales funnels, too.

By now, you’re probably thinking, “This is great, but you still haven’t told me how I can know what to test.” First, let’s discuss what a test looks like, and then we can review some things you can think about to help generate test ideas.

Here is an idea of what a test could be:

• Changing the primary colour of our search button: In my current company, a simple colour change to our search button caused a six-point drop in search completion. Making that same button dynamic (active only when the search field changes) brought us back to our baseline and generated an additional three-point increase in search completions.

Here are some things you can try:

• The Reverse Test: Test turning it off; there may be things you can remove

• Simplify and combine: Test removing form fields, steps in a process, number of options

• The default test: What is the default setting? Try changing it in every way imaginable

• Split it: Make one section into two, or create multiple steps from a single screen

• Change the design: Make a text link a button, change text size, colour, shape, imagery

• Text: Different copy, new messaging, new button text.

• Layout: Move it up the page, down the page, try a 2-column or 3-column layout

• Communicate: Better communicate to users where they are in a flow, what the next steps are, and what just happened when they clicked that big red button.

You can still leverage existing data to inform your tests. User reviews and conversion performance at various stages of your funnel can point you in the right direction. But, in practice, users rarely tell you explicitly that a button needs to be a different colour or that the layout doesn’t work for them. And if they do, you won’t know what option is better without a quick test.

However, rapid experimentation doesn’t happen without the right systems and processes at the development, infrastructure, and planning level. Your developers must be unencumbered by technical debt, experiments must be easy to create, and everyone needs autonomy to do this without facing a bunch of red tape or bureaucracy. At its core, rapid experimentation requires the ability to do dozens of releases a day, show some things to some users, and track the results of what’s happening.

Do you want to start rapidly experimenting within your company? Follow these steps to get started:

• Hold a retro with engineering to learn what keeps them from moving faster. Funretrospectives.com has some great options; I recommend anchors and engines as a one-off or the sailboat format for an ongoing view of what’s holding you back.

• Start by setting a realistic goal for the number of tests you’ll create during your next cycle based on your team’s current capabilities. Push the boundaries of what’s been done before.

• Create a list of things you can test. Involve the whole team in a brainstorming session if you like; great ideas can come from anywhere.

• Get started!

I’m going through this process at my company right now. For an early stage startup we move pretty slow, but shifting culture is hard. To get more updates on that journey and other helpful Product Management perspectives, be sure to subscribe to this newsletter.

If you’re looking for more guidance on how to operate as a product manager within your company and it’s unique challenges, I still have some coaching slots available through Mentorcruise for next year. You get an introductory call for free, and I have various coaching options available.