Your product manager should be facing inward AND outward
Let's start by asking how your product backlog is managed. How do items get on the backlog, and how do items get picked up from that backlog for development? Who does the former and who does the latter? In (software) product development, there usually are people with two important roles that divide these tasks between them.
- The outward-facing role is market-facing. Someone in this role speaks to the customers and users, investigates market opportunities and defines high level requirements for the product. This role is very important, since you can only define the right thing to be built by looking at your market. What do the users need exactly? And what do you need to deliver to achieve the best product-market fit? In a typical organization, this role is usually taken up by people with the function of Product Manager, Product Marketeer, CEO / CxO or Business Analyst.
- The inward-facing role is development-facing. Someone in this role manages the development backlog for a (Scrum) software development team and defines and prioritizes the detailed product requirements. This role's importance shouldn't be underestimated, since requirements need to be correctly translated to- and implemented by- the (software) development team. If done incorrectly, no products would ever see the light of day. In a typical organization, this role is usually taken up by a Product Owner, Functional Analyst, Architect, or Lead Developer.
Both roles are always present in a product organization, sometimes implicitly, other times explicitly. Usually, the outward-facing and inward-facing tasks are divided across different people: two roles, two persons.
In this blog post, we'll explore why splitting the outward- and inward-facing roles across different people is not a great idea and, in fact, causes a few problems.
Why splitting the outward and inward roles causes problems
Although many organizations split the outward- and inward-facing roles, most thought-leaders in the product community argue against it (read more about that here, here, here and also here). Splitting outward and inward roles across different persons has some fundamental flaws.
- There is more distance between the actual development team and the user. The development team makes hundreds of decisions concerning the product every week. Without a deep understanding of the customer and the user, these decisions can never be well-informed.
- It introduces an extra communication hop: from user to outward-facing to inward-facing to the development team. This enhances the 'throw over the wall' problem. Even the high level requirements get misinterpreted. This results in 'cake wrecks'.
It is not the managers interpretation that is put into production, it is the developers misinterpretation that is put into production.
— Alberto Brandolini, EventStorming creator at Alberto Brandolini
- The split model is based on a fallacy: the idea that the transition from high-level requirements to detailed-level requirements is a one-way direction. The high-level requirements are usually defined by the outward-facing person. The detailed requirements are defined by the inward-facing person. However, this is based on a flawed view of software development: high level requirements can not be defined independently of detailed requirements. The latter will always have an influence back on the former. Splitting this task between two different people causes a tremendous overhead in communication, collaboration and alignment.
- With split responsibilities, there is often no clear owner of the product. Neither person acts or feels fully responsible for the product.
A Product Manager should encompass both roles
To address the above problems, it is better to have only one person responsible for product definition. Outward-facing and inward-facing, operating at high-level and detailed-level, market-facing and development-facing. Two roles, one person. There is only one person responsible for the product, which minimizes the handovers and shortens the distance between development and user. In the product world, this one person is usually given the job title of Product Manager. They are responsible for the entire product development cycle:
- Product Discovery (outward-facing)
- investigating market opportunities,
- defining a clear product strategy,
- talking to users and customers and analyzing their needs,
- aligning all stakeholders,
- creating and testing solution hypothesis.
- Software Development (inward-facing)
- managing the solution backlog (e.g. User Stories),
- defining priorities,
- discussing and collaborating with the development team about the requested features,
- validating delivered work.
In just one day, the Product Manager can have a discussion with the development team about user story X, a user interview to investigate the market, a discussion with the CEO about the future of the product and a Scrum planning meeting with the development team.
Product Owner is a role you take up in a Scrum team, Product Management is the job.
— Melissa Perri, speaker, consultant, teacher product management at Melissa Perri
What has not changed is my overarching belief that behind every great product, there is someone, usually someone behind the scenes, working tirelessly, that is playing this critical role. They usually have the title ‘product manager’ but they might be a startup co-founder or the CEO, or they might be in another role on the team and stepped up because they saw the need. The title is not important; the work they do is.
— Marty Cagan, Founder & partner at Silicon Valley Product Group
Tips for distributing all that work
But, but, .... I can never handle the vast market, do user interviews, perform my discovery process, define a product strategy, handle detailed specs, manage my story backlog and my development team all at the same time. This is impossible!
Yes, product management is a lot of work. This is one of the reasons why the split between roles is still so prevalent in a lot of companies (e.g. having a Product Manager as well as a Product Owner). It divides the workload across different people. To circumvent this scalability problem and not having to split the roles into outward- and inward-facing, here are two techniques you can use.
- Duplicate the Product Manager. In stead of having a broad-scope outward-facing person and a broad-scope inward-facing person: have two Product Managers, each focussing on a more narrow domain within the product space. Each Product Manager is responsible for their part of the domain: outward- and inward facing, high- and detailed level. Generally, splitting your product space into different (sub-) domains and having (separate) teams responsible for each domain is a good idea. These are lessons learned from Domain Driven Design (DDD), the Spotify Model and Conway's Law. Aligning the Product Manager with this structure enhances the scalability across the product. Note: you still need an overall product vision for the entire product to set the boundaries within each problem domain. Inside the domain, however, the responsibility lies completely with the owning product manager.
- Let your team support you. Build yourself a Core Product Team consisting of the necessary experts: technology, UX and business. Assign the discovery and development work across the team members. But make sure that, as a Product Manager, you keep the accountability of the product domain. One step further, the whole development team can be involved and help with product discovery, minimizing the handovers and distance to the user. This is known as dual-track development. We've covered this topic in another blog post, feel free to check it out for more information.
A good product owner is a business advocate, a customer advocate, a subject matter expert, a user experience expert, an engineer, a top notch communicator, and a visionary leader. That sounds like a bit of superhero to me. In the absence of a superhero, you’ll need to build skills, to build a team with skills.
— Jeff Patton, Author at Jeff Patton
Takeaway
In conclusion, make sure you organize the product (team) structure in a way that involves everyone and circumvents the issues with splitting between outward- and inward-facing roles. Have one person responsible for both roles, within the boundaries of their own sub-domain. If necessary, duplicate your product manager. Minimize the handovers, shorten the distance between development and user, and have a person who is clearly responsible for the product (domain): high- and detailed level.
Want to know more about product management? You can contact me directly for more information.
