Product Management Approaches: Top Down, Bottom Up or Both?

As a product manager you have a lot to consider when you’re planning and working on the vision, objectives, roadmap and backlog for your product, including where the input for all these aspects of your product comes from. You can either focus on a “top down” approach based on directives from senior leaders, or take a “bottom up” product management approach which starts with your ideas and works up.

But which is the right approach to take? Obviously finding which one works for you is really important to success. But, I’d like to suggest that it’s not a case of taking one approach versus the other, it’s both.

Top Down

What do we mean by a “top down” approach to planning? It’s the information provided to the product manager by the senior levels of the organisation (or if they’re lucky, produced in collaboration with the leadership team). The first of these is the vision.

Vision

Often the company’s founder/CEO will have a vision which acts as a guiding star for the long-term focus of the product. Steve Jobs once said: “If you are working on something exciting that you really care about, you don’t have to be pushed. The vision pulls you.”

So vision is quite lofty. It means there’s little you can actually execute on, but knowing the ultimate goal for the product can help you to make day-to-day decisions about which problems to solve, and also help you decide what NOT to build. For example, implementing a gamified onboarding solution is really important if your vision is to build an B2B internally-facing self-service SaaS application. However, as your product vision is to enable internal stakeholders to achieve results, there is no value in adding a feature for customer communication, as that’s not part of the vision. The vision for your tool (i.e. being an internally facing self-service application) has guided the decision-making on which features to build and which features are out of scope.

However you may decide not to build in an emailing service if it’s not the core focus of the application.

Objectives

Where vision gives you your guiding star, objectives tell you whether you’re moving in the right direction *before* you get there. Imagine you’re given a destination but you have no information about the distance remaining while you’re traveling, that’s what it’s like if you have a vision but no objectives. You have no idea if you’re going in the right direction.

Objectives take the form of measurable OKRs, KPIs, metrics and so on – whatever term you like to use – because you need to know that the work you’re doing will deliver the right outcome. Imagine you have decided that your objective is to increase user growth or reduce churn. Over time, you can see how the work you do affects those metrics, and adjust your plans depending on the results. Objectives are part of your “top down” planning process – they are the guardrails that help you to stay on track.

By measuring key objectives like customer acquisition, revenue, conversion, retention, engagement, user growth, and usage, we can see which areas of the business are performing well and which areas need some attention – and that means we can prioritise which objectives to focus on.

Initiative

You have a vision and you know how to measure your progress towards it – but that doesn’t tell you what to deliver. To be successful, you need to solve customer problems, and this means you need an Initiative.

An initiative is a high-level description of a problem you want to solve, something you want to build. It’s still not detailed enough for your delivery teams to execute on, but it gives them a better idea of what they’re building – so that together with the objective to which it contributes, you have “What” and “Why”.

Let’s go back to our earlier example of the user growth objective. There are many things you could build that contribute to an improvement in user numbers – perhaps a referral program that leverages your existing user base or a redesign of your marketing site to increase the conversion of visitors to subscribers. All of these are initiatives – high-level plans for work you could do to improve your metrics and get closer to your vision.

Building Your First Roadmap

We should pause here. We have a vision, some objectives and a list of initiatives. We know which objectives are the most important for us to focus on. We now have enough information from our “top down” planning to create our first roadmap. It could look something like this:

So far so good. We’ve built a roadmap, so surely that’s all we need? Unfortunately, the answer is no. You can’t just work from a roadmap, as it means you’re likely to miss many opportunities – changes in the market, new competitors and the like are all missed if you blindly follow a roadmap, even if it’s really well aligned with a vision and tied into objectives.

You wouldn’t and shouldn’t expect your 2018 roadmap to look the same in another 12 months, it’s normal and natural to change it as you learn. This is why you need a flexible format, which gives you the ability to build in any insights gleaned from a bottom-up product management approach where you constantly assess opportunities. This is the only roadmap format that works in practice. In order to make that work, we need to start our “bottom up” planning.

Bottom Up

Our roadmap shows a list of initiatives (the “What”) and the objectives which will be affected when changes are made (the “Why”). In order to execute these initiatives, we need more detail – and we need to be lean and agile – and to be able to adapt our product management approach based on what we learn along the way. That’s why we need to break down those large initiatives into individual changes which are manageable and can be delivered. For that, we need ideas.

Ideas

A list of ideas is a list of changes that may (or may not) be worked on to improve the product – our product backlog. There are always more ideas in our backlog than we have time to deliver – and that’s a good thing, because it forces us to select the ideas for our product that are most likely to bring us (and our customers) success. The godfather of product management, Marty Cagan, calls this the opportunity backlog.

Ideally, an idea should outline the problem, the solution and the expected outcome if the solution is implemented. This information means that the idea’s business impact can be identified. Business impact is a measure of how much benefit users will gain – and therefore the value of the idea to our business. If we have an outline of the solution, we can estimate how much effort is involved in delivering the solution. Having these measures in place gives us the ability to prioritise – we can select the ideas which provide the best return on investment (the quick wins).

Plotting impact vs effort allows us to see the ideas that are quick wins (1), the ones which are valuable but complex (2), the ones which are time sinks (3), and the ones which will only be valuable if delivered as a cohesive group (4).

Of course, once we have identified that the idea is worth delivering, we need to ensure there is enough information for the development team to pick it up and action it. That requires another level of detail, with user stories, designs, functional specs all part of our idea’s definition. (More on that in another of our blogs, here).

So how do you obtain the ideas in the first place? They can come from users of your product, potential customers or internal stakeholders – or maybe even as a result of research you carry out into the market and your competitors. If an idea has arisen from customer feedback, then tracking the source of that feedback is valuable, as it can help you to understand the depth of the problem you want to solve.

Customer Feedback

The chances are that you already have access to customer feedback via a number of sources. It’s vital you make the most of it, and use it to identify trends, establish business value, build confidence with your customers and drive feature adoption.

But how do you achieve that? There are a number of best practices which we in the ProdPad team recommend and take advantage of ourselves.

Collect Customer Feedback

Think about all the interactions between your company and your customers. Your sales team, your customer success/support teams, operations, professional services, marketing, user experience – they all have contact with customers and end users, and hear lots of snippets of information about how your product is used. They might be using email, Slack, Zendesk, Intercom, Salesforce, face-to-face meetings, phone calls – many different ways of communicating. In an ideal world, they would tell you, the product manager, about everything they hear, but as this requires them to deviate from their day job, it needs to be easy! That’s why ProdPad includes lots of way to collect customer feedback – more on that here! However, let’s assume you are building up a backlog of collected feedback and want to maximise its value. How can you do that?

Link Feedback to Ideas

Firstly, you need to connect the collected feedback with the ideas in your backlog. Each Idea is likely to be supported by one or more customer requests – in fact having good market fit means you’re probably hearing the same thing over and over again. Imagine you have two ideas in your backlog, one of which is supported by feedback from 12 different customers, and one which is supported by 45 different customers. You can then understand which idea is more valuable to your customers and your business.

Collaborate With Feedback Contributors

If you’re ready to start developing a new idea what’s the best way to ensure you’re building the right thing in the right way? Run it past the people who asked for it! As well as helping you with prioritisation, keeping track of the customers who requested a solution to your problem gives you a ready-made list of beta-testers, or contributors to your user testing. Not only will it help you to get the solution right, it also gives your customers a nice, warm glow – they told you about something and you are acting on it, using their input!

Once the feature is delivered, this list of people can also act as your early adopters – so let them know about the new feature when it is released and get adoption off to a great start!

The Advantages of Bringing Everything Together

We’ve talked about the top-down approach, where we take guidance from senior stakeholders and use it to build a high level roadmap – the prototype for our strategy. We’ve also talked about collecting customer feedback and using that to support and help maintain our product backlog. But how do the two planning methods work together?

This is the fun part. Looking at your roadmap, it should be possible to connect ideas in your backlog (particularly those with good evidence from customer feedback) to the initiatives you’ve identified as being worthwhile. That home page redesign you’ve talked about? Well, it looks like you have customer requests for improved navigation, or feedback from your sales team that the sign-up page is too complicated. Maybe someone has mentioned that a video which explains your product would be a big help. All of these fit into your “Home Page Redesign” initiative, and so you are able to marry up the top-down planning with the information you’ve collected from customers and internal stakeholders. This is the best possible outcome, as you’re using the information from the coalface to move in the direction laid out by the company’s leadership.

The result is a roadmap card that looks something like this…

It has high-level information about what is being done and why. It allows for changes in scope to be made – you can add and remove ideas without the need to change the initiative – so your roadmap is both agile and predictable. You can tailor the level of information you share depending on the audience – customers, sales, investors and C-suite may only need to see the objectives and initiatives, whereas development and the marketing team will want to see the detailed Ideas. And you know you’re delivering features that will please your customers while also moving the needles that you need to move.

So, top-down or bottom-up? The answer is both!

Looking for more PM advice? Try our product management blog for more top tips.