Of all the roles in a modern software development organisation, Product Manager is one of the hardest. After all, Product Managers should act as “Mini CEOs” of their product. Some might dispute that moniker however.
Product Managers need tried and tested tools and methodologies in order to support their role.
Many exist. Here I will briefly provide an overview of just a small fraction that can provide value at various stages of the software product development lifecycle.
Ideation and problem structuring
Design Thinking is a human-centric design methodology that can be applied to finding solutions for ill-defined or unknown problems. Design thinking uses ethnographic research to identify key frictions and pain points in order to fully understand a problem from an end user’s perspective. Solutions to that problem can then be iteratively tested using prototypes and mockups based on a set of design principles derived from user research.
But what happens if the problem is not ill-defined, rather the solution space is complex? Or perhaps there is an existing process that simply needs to be optimised?
In the first case Morphological Analysis can be one (of many) potential tools that can be applied. Morphological Analysis, developed by Zwicky, is a structured method for exploring a complex, non-quantifiable solution space. Useful introductions to this topic can be found here, here and here.
For the latter case (optimising an existing process), Value Stream Mapping would be more appropriate. This technique involves visualising the steps required from developing the product to serving the end user. The focus is then to utilise the resulting map to eliminate waste from the process. While this was technique was originally developed with manufacturing in mind, it also applies to software development. For example, see this blog post on how it was applied at Soundcloud.
Business Model and Value Proposition
A well articulated value proposition and workable business model are of course vital aspects of product development. In particular, understanding the underlying cost structure and the value a product delivers to the end user from the outset will make investment decisions easy. A great way to structure thinking around these topics is to make use of lean templates such as the business model or value proposition canvas. Alex Osterwalder’s work in this area has been particularly influential.
Any upfront planning is full of assumptions. Prior to investing large amounts of capital into a product build, it’s desirable to test as many of these assumptions as quickly and cheaply as possible. Advocating the mantra of “fake it before you make it”, Pretotyping is an approach to testing product features that involves creating mockups in hours or days rather than weeks or months. In particular, this approach lends itself well to the Design Thinking methodology discussed previously.
While pretotyping is mostly applicable to the pre-build phase of product development, post-launch assumptions also need to be validated. Features also need to be optimised. The standard practice is to apply split testing. This is not as straightforward as it may sound however, and can often lead to false inferences. One principal issue for split testing new products is the so called “cold start problem”, where there is insufficient data to gather meaningful statistics on product performance. This is often an issue with traditional Frequentist approaches to analysing data for products and services delivered via the web. Using alternative methods to analyse split test data such as Bayesian statistics is a good option. An introduction to this topic can be found here.
The product backlog is the central tool in any product build. The principal issue is prioritisation. A large part of prioritisation is quantifying opportunity cost, or more simply put, estimating the cost of doing one thing over another. A common tool applied in finance, and increasingly to product development is cost of delay. This requires a good understanding of the expected value and duration of features. See here and here for details.
Alternative visual representations of a flat product backlog are very useful for stakeholder management. A user story map is a visual representation of the journey a user takes with a product. The map splits the backlog into the high level activities a user will carry out when using the system, detailing the tasks required to complete those activities and when this functionality will be delivered, making the timing transparent for stakeholders. See here for a concise overview of User Story Maps.
Execution involves ensuring rapid delivery of a product that serves the target market as well as possible. To achieve that, a software development process is required that can mitigate the risk associated with the product build by ensuring value can be delivered incrementally in short and frequent cycles. Lean Software Development provides principles on which to develop such a process. Below I briefly summarise some of those principles:
The Product Manager role requires knowledge of a diverse set of skills: Business, Software Development, Design and Statistics to name just a few. Hopefully the tools and methods discussed in this post can prove useful for some.