This is an excerpt of a case study from the Holistic Product Discovery book. Concepts explained deeper in the book are emphasised.
Prelude
A team whose mission was to build and maintain a game operations platform for operators and developers at King had realised a year back that they needed some developer tools for building applications for that platform. This realisation came through feedback that it was hard to start creating applications, regardless of the knowledge and experience of the developer. The idea for tooling and support for the platform developers to fulfil their needs was born.
A prototype was made with focus on creating an application package to easily start developing for the platform. The prototype of the functionality was validated through user testing.
Some time after that, workshops around creating an ideal user journey for the platform developers were held including a good spread of platform developers and development team members. A first release was identified in a User Story Mapping session, with a focus on learning what would work or not.
Concurrently, the development team learned of an open-source portal for platform development and also about implementations of that portal in a few other different companies.
These two events led to the creation of an interaction design of the first release, based on the open-source portal, which
eventually was implemented. When live, this new portal for platform developers was tested with a core group of users with good results.
We can summarise these events in the Holistic Product Discovery Framework through a historic angle:
A few things we can learn from viewing this and the project at that stage is that work was unstructured, for better or worse. Discovery activities happened ad-hoc and in an uncoordinated fashion, but they happened for a reason. There were probably activities that would have been good to do that were missed, thus not getting a more holistic viewpoint. At the same time, the development team had learnt a lot more than they would have without Discovery, which guided the project’s direction. And by just looking at the figure, we can see that the solution focus in the project so far was significant.
At this stage the project took another turn for a few reasons. One, the open source portal used made it easy to get documentation for the platform applications into the platform developer portal, which led to the platform developers quickly adopting it. The user base grew. Two, there was an opportunity to expand the functionality in the platform to support an ongoing migration to the cloud, expanding the target group to include non-platform developers as well, possibly supporting all developers at the gaming company.
The development team realized that they needed more help with doing deeper Discovery for the new functionality and by using the historic angle, we quickly saw that Problem Discovery for the whole project was needed.
Risks and assumptions
At the start of the second stage of the platform developer portal project, now called Foundry, there were a lot of assumptions, both in and around the development team. This led to us deciding to do a risk workshop on a more abstract level where we listed assumptions and categorised them based on risk types as well as severity. The severity rating (namely “no risk”, “low risk”, “medium risk” and “high risk”) helped us decide if deeper Discovery was required for an assumption or not.
We created a board based on the risks and the Holistic Product Discovery Framework that would help guide us through the project.
This made it possible for us to plan the work ahead of us and to work in parallel (a way to do continuous Discovery and Delivery using a so-called Discovery Kanban way of working). Some smaller things we just started to build, some things needed some design, short analysis and definition, and some larger things needed Discovery. No assumptions ended up being classified as high risk.
Impact mapping
What we could see was lacking, based on the historic angle of the previous part of the project, was exploring and structuring business value and user value problems. We began the work with a strategic Product Discovery approach using the so-called Impact Mapping technique which is mainly used to just “structure user and business value problems.” This helped us understand the goals from the organization’s perspective on why a platform developer portal was needed. It also helped us map out the different kinds of users in our target group.
User research
That last part made it obvious that we had a larger spread of users that we needed to understand, including our already adopted ones. We wanted to find out what their needs were. We moved to the “explore user value problems” of the framework and decided on interviewing them one by one.
The data from the interviews (with approx. 20 different developers well spread in the target group) needed structuring and we moved to the “structure user value problems” of the framework and decided on doing a collaborative analysis of data mapped visually on a board. Insights from the interviews were drawn, and then structured and prioritized in the Business impact map.
User story mapping
The insights, expressed mainly as user needs and a few user behaviors, formed the foundation of a larger solution brainstorming session and prioritization similar to step 4, 5 and 6 of the User Story Mapping technique proposed by Jeff Patton. This solution brainstorming was done since we’ve spent quite a long time in Problem Discovery and the context gave the opportunity for switching over to doing more Delivery for a while in our Discovery Kanban way of working.
The first part of the exercise was brainstorming solution ideas, the second part of the exercise was prioritizing based on business value, user value and feasibility, and third part was prioritizing based on risk.
The same severity scale for risks was used that we had used previously and this time we had one note in the map being classified as high risk. This High-risk Discovery part of the project is explained deeper in the book.
The last part of the exercise consisted of deciding about the other solution ideas, if they were either going directly into Delivery, or through Definition first, or should be prototyped and evaluated in Solution Discovery in the future.
Insights
Looking back, using the historic angle on our guiding angle board, it is obvious that we have not explored the business problem enough. At this stage, more exploration is what is next up for the development team to discover, most likely through stakeholder interviews, before going further ahead in the solution space to make sure nothing gets built that isn’t the right thing to build.
Note that there was also ongoing Feasibility Discovery, where the development team evaluated different technologies, created spikes and proof of concepts as well as evaluating those along the way.
The visualization is now getting quite crowded, but it is a necessity to be able to be guided through the Holistic Product Discovery Framework in a good way. We used a digital board with unlimited space to be able to get a good overview and be able to zoom in on the details.
In general, the team worked with cadences and signals to know when we should do mainly Discovery in the team or mainly Delivery. When the team received new information, that led to new questions, and glancing at the guide angle board helped us understand what Discovery activity we should perform. When the questions felt answered well enough, we changed perspective to Delivery.
The team learned the Product Discovery & Delivery mindset switching very well along the way and could change the playbook we created when needed on their own.
Here is the summary of this case study.
Leave a Reply
Want to join the discussion?Feel free to contribute!