Join the Mastering Agility Discord community!
This article continues from the Product Wall introduction article. These series are co-written with Ryan Brook based on our upcoming book. You can download our free Product Wall Mural template here.
Now we have covered the general overview of the entire Product Wall, we break it down piece by piece. In this article, we explain the Market and Domain Information section.
If there is anything we would absolutely love to see more often, it would be active market and domain assessment by Product Owners. Product Owners are accountable for maximizing the value that is generated by the product the Scrum Team creates. Knowing where your product stands relative to the competition, or how many of your products have been sold is essential information to decide on the next steps to take. It can balance out conundrums like "can we build this product, and should we do it?".
Going upstream
Let's put that into a different perspective and take the streaming service market. There are currently over 200 streaming services worldwide, some with a marginal difference compared to others, while some offer a very specific niche like Formula 1, UFC, NFL, and so on. These streaming services are available from any device, anywhere in the world. Now imagine that we start a new company to build an entirely new streaming service, with an overlapping offer that competitors offer. As a unique selling point, we box our streaming service into a new TV. So customers would need to buy our TV to use our service. A couple of questions would arise during investor meetings.
- Can we build the hardware? YES!
- Can we build the software? YES!
- Can we integrate both and build a solid product? YES!
- Would this product be sellable on a wide market? Highly unlikely.
Why though? Just that we can, doesn't mean that we should. Does this scenario really enable a better service to our (potential) customers? Maybe some of them, but adding more features or locking in what the customers need in a device the vast majority already has just creates waste. Data mapped in Market and Domain Information can help drive this conversation. Let's have a look at the Magnum Opus example.
Like all the other elements in our Product Wall, these are just examples. You can replace them with whatever you deem useful. Remember that metrics, by itself, bear no value. Value is online an assumption until you deliver something into the hands of the user. We get to value by using data and metrics to base decisions on to lead the direction of the product.
This example has three areas:
Market share relative to the competition: Where do we stand when it comes to our competitors? Are we in a position where we want to be? What are they doing differently than we are that we could leverage? Or what can we think of to keep our strong position?
Top airport trends: What are the current trending topics in airport security? This one is related to the case study we use in the book to illustrate development, but this could change to any type of product or organization. In this case, the trends are used to make a product fit the predicted needs of the airports Magnum Opus is serving.
Geographical map: Nothing else than a visualization of the areas where our products have been sold. If you plan to be the leading entity in Europe and your map shows Asia as the main selling market, you might need to adapt your plans. Visualization is an incredibly powerful way to make certain things adamantly clear.
# of active MO products per airport: This could be translated to the number of products sold per region/area/whatever. In this, we have a look at our customers, how many of our products are in active use, and whether it's an increase or decrease. The immediately makes clear where most products are. This can provide links to geographical areas and other areas of the Product Wall.`
Feeding back to the log
Sprint Reviews are perfect events to discuss these elements together with your stakeholders and team. Information radiators like the Market and Domain Information component support argumentation for certain decisions as a Product Owner, in turn, creating more trust and transparency between the stakeholders and Product Owner. Coming back to the funding discussion we discussed in the Roadmap article, investors (a form of stakeholders too) will be more likely to invest in your product and buy into the vision you set. As an example, tools like this, combined with the Roadmap, can be used to figure out potential work to move ahead of the competition and how much investment it would require.
None of this would matter if it wouldn't be used to support the direction and creation of value itself. A short reminder that a product is defined in the Scrum Guide as "a vehicle to deliver value". So all of these ideas, feedback, and concepts are directly put into the Product Backlog, to create transparency and common understanding about the work that needs to be done. The next step is to link it to groups of stakeholders to figure out who needs what, so stay tuned for our next article!