{"id":5666,"date":"2018-07-24T10:28:32","date_gmt":"2018-07-24T09:28:32","guid":{"rendered":"https:\/\/www.prodpad.com\/?p=5666"},"modified":"2023-05-04T17:06:50","modified_gmt":"2023-05-04T16:06:50","slug":"product-management-approaches","status":"publish","type":"post","link":"https:\/\/www.prodpad.com\/blog\/product-management-approaches\/","title":{"rendered":"Product Management Approaches: Top Down, Bottom Up or Both?"},"content":{"rendered":"\n

As a product manager you have a lot to consider when you\u2019re 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 \u201ctop down\u201d approach based on directives from senior leaders, or take a \u201cbottom up\u201d 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\u2019d like to suggest that it\u2019s not a case of taking one approach versus the other, it\u2019s both.<\/p>\n\n\n\n

Top Down<\/h2>\n\n\n\n

What do we mean by a \u201ctop down\u201d approach to planning? It\u2019s the information provided to the product manager by the senior levels of the organisation (or if they\u2019re lucky, produced in collaboration with the leadership team). The first of these is the vision.<\/p>\n\n\n\n

Vision<\/h3>\n\n\n\n

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

So vision is quite lofty. It means there\u2019s 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\u2019s 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\u2019s not the core focus of the application.<\/p>\n\n\n\n

Objectives<\/h3>\n\n\n\n

Where vision gives you your guiding star, objectives tell you whether you\u2019re moving in the right direction *before* you get there. Imagine you\u2019re given a destination but you have no information about the distance remaining while you\u2019re traveling, that\u2019s what it\u2019s like if you have a vision but no objectives. You have no idea if you\u2019re 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\u2019re 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 \u201ctop down\u201d 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.<\/p>\n\n\n\n

Initiative<\/h3>\n\n\n\n

You have a vision and you know how to measure your progress towards it – but that doesn\u2019t 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\u2019s still not detailed enough for your delivery teams to execute on, but it gives them a better idea of what they\u2019re building – so that together with the objective to which it contributes, you have \u201cWhat\u201d and \u201cWhy\u201d.

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.<\/p>\n\n\n

\n
\"Revenue,<\/figure>\n<\/div>\n\n\n

Building Your First Roadmap<\/h3>\n\n\n\n

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 \u201ctop down\u201d planning to create our first roadmap. It could look something like this:<\/p>\n\n\n

\n
\"Now<\/figure>\n<\/div>\n\n\n

So far so good. We\u2019ve built a roadmap, so surely that\u2019s 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 \u201cbottom up\u201d planning.<\/p>\n\n\n\n

Bottom Up<\/h2>\n\n\n\n

Our roadmap shows a list of initiatives (the \u201cWhat\u201d) and the objectives which will be affected when changes are made (the \u201cWhy\u201d). 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\u2019s why we need to break down those large initiatives into individual changes which are manageable and can be delivered. For that, we need ideas.<\/p>\n\n\n\n

Ideas<\/h3>\n\n\n\n

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\u2019s 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<\/a>.

Ideally, an idea should outline the problem, the solution and the expected outcome if the solution is implemented. This information means that the idea\u2019s 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).<\/p>\n\n\n

\n
\"Idea<\/figure>\n<\/div>\n\n\n

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\u2019s definition. (More on that in another of our blogs, here<\/a>).

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.<\/p>\n\n\n\n

Customer Feedback<\/h2>\n\n\n\n

The chances are that you already have access to customer feedback via a number of sources. It\u2019s 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.<\/p>\n\n\n\n

Collect Customer Feedback<\/h3>\n\n\n\n

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\u2019s why ProdPad includes lots of way to collect customer feedback – more on that here<\/a>! However, let\u2019s assume you are building up a backlog of collected feedback and want to maximise its value. How can you do that?<\/p>\n\n\n\n