The big picture
In thinking about the world of digital Product Management, it is useful to zoom right out and consider a “big picture” view of what really matters in the product world: in other words, the principles and modes of thinking that really make a difference.
First, here are 3 observations that shine some light on how difficult it is to successfully steer software products.
Product Management Is multi-disciplinary
As well as demanding some subject matter expertise in the product’s domain, Product Management also draws on concepts from business, technology, marketing, psychology, and operations. And this is not an exhaustive list.
Product Management must align with corporate goals
At the risk of stating the obvious, Product Management must align with corporate goals. There is little point developing a product (no matter how clever) that does not further the goals of the organisation funding it. The most common corporate goal is to make money, but equally important goals can be things like improving the lives of customers or achieving positive social change. These goals are not mutually exclusive, of course.
Product Managers have lots of direct accountability, but often they have little direct authority
Product Managers are accountable for product metrics like number of subscribers, retention rate, revenue per user, and customer life-time value. Yet rarely do Product Managers work directly on any tangible product artefacts: specifications and user stories are written by business analysts, designs and patterns are decided by architects, code is written by developers, builds are validated and verified by testers, software is deployed by engineers, branding and positioning is done by marketing, deals are closed by sales, tickets are actioned by support staff.
Basically, Product Managers need to wear many hats. They need to somehow align their product with corporate goals, while simultaneously achieving results with little or no direct control over the actual work.
So, where to start?
You need to know something about your constraints. How big is your budget? How long do you have to get to market? How mature is your organisation? How complex is the product you are building? Understanding constraints involves a lot of operational business thinking. You’ll need to understand things like who approves budgets, who controls costs, how the organisation assembles and assigns teams, the way talent gets managed, project management methods.
Once you know the constraints, ask yourself what your product goals are. This is hard stuff. You need to know the organisation’s goals and how your product can help the organisation achieve them.
You need to learn this from the stakeholders, which will differ from company to company. In an early stage start-up, this might be the entrepreneur who founded the business. In a large multinational software company, it might be the combined perspectives of many players – marketing, sales, engineering, board members. Distilling corporate goals can take time. Figuring out how your product contributes to their achievement can take even longer.
Whilst these are significant topics in their own right, this is a “big picture” post, so we’ll assume for now you’ve figured out your constraints and goals in enough detail to get started. Once you know your constraints and goals, you can put a plan together.
Something like this:
Simple. We’re done. Right?
Not so fast
As you start building the product, you will want to get it out into the market and in use by customers. These might be early adopters or “beta testers” or they might be your general market, depending on the product and the context. Regardless, in all situations, you will want to collect feedback from both the market and customers.
This feedback tells you useful things.
Feedback from the market tells you about changes in the world that impact your plan.: things like the entry of competitors, political and legal obstacles, and societal changes that affect your organisation, your customers, and your product.
Feedback from customers tells you if you are the right track with the product itself and how customers are using the product which you can compare to how you intended them to use the product.
Plans vs strategy vs tactics
Learnings from the market and your customers will inevitably make you re-think your plan. You will chart a new course to your goals. In fact, even the goals themselves might change. Don’t be afraid. This is normal.
To put this in perspective, let’s consider a hypothetical software company that started developing apps to play digital music in the early 2000s. When the company started, the dominant paradigm was for customers to download music as files (one file per track). The dominant file format was MP3. The company developed a beautiful app with features like playlists, transferring between formats, and music recommendations.
The trouble was, by the time they put the app into the market and gathered a customer base, music streaming technologies were disrupting the entire music industry. At this point, Product Managers ignored market and customer feedback at their peril. The goal shifted to building apps with streaming capability, which in turn meant plans had to change. Only by seeking signals from both the market and customers could Product Managers hope to proactively deal with these new circumstances.
A useful way to illustrate it in the context of Product Management is to separate strategy from tactics. Strategy is what you need to do to succeed. Things like business plans, product roadmaps, customer journeys, user stories, story maps, marketing plans. Tactics are how you will do those things. Things like development practices, agile methods, ticket tracking systems, programming languages, design tools.
Considered together, a plan is what and how you will achieve your goals.
As a formula: Plan = Strategy + Tactics.
Breaking this down a bit, what you are really doing is using market and customer feedback to adjust your strategy and tactics. The most reliable way to do this is to adjust course by learning what the evidence tells you. Management theory variously characterises this basic concept with fancy sounding names like “Plan-Do-Check-Act”, “Control Cycles”, “Continuous Improvement”.
Smart Product Managers adjust strategy and tactics by measuring the right things.
We can generalise further and see that ongoing Product Management is the continual process of taking change into account by measuring and improving both strategy and tactics (and adjusting the goals, if necessary). This leads us to a picture consistent with the flexibility of agile methods, which acknowledge that change is inevitable, that we should embrace change, and that we should put it at the heart of everything we do.
In conclusion
The above analysis probably makes Product Management sound pretty straightforward. It is not. The reality is that putting the right strategy and tactics in place – and being agile enough to adjust course on the fly – is complex. It is also why the job is so rewarding. The most successful Product Managers have a broad knowledge of many disciplines – things like finance, org structures, operations, data analysis, design, marketing, business cases, psychology, engineering – and the ability to “join the dots” by bringing all of these together into a cohesive plan. The trick is to know “just enough” and avoid getting bogged down in any one area.
Rewinding to the three observations made at the beginning, we’ve covered the first 2 in detail: (i) Product Management is multi-disciplinary and (ii) Product Management must align with corporate goals.
The third observation is just as important: (iii) Product Managers have lots of direct accountability, but little direct authority.
This means that even as you continually steer the product ship by ensuring your plans (strategy and tactics) have you headed for your (shifting) goals, you may not even directly do any of the work!
The best you can do is listen to the passengers on the ship (customer feedback), observe the ocean and weather (market feedback), and communicate effectively with your team of skilled sailors (the people who do the work). The best Product Managers empathise with other’s points of view and learn how to persuade and influence others to buy into – and stick to – the (constantly changing) plan.
Go forth and steer your products.
It’s simple, right?