Product Discovery in Platform Teams
The Product Discovery Plan
Welcome back to another autumn edition of the Platform space. I skipped my usual weekly content last week to the detriment of finishing another peer-review paper. I am getting back into a rhythm of context-switching when it comes to writing (I think!)
Resuming my regular Friday schedule, I am returning with a piece on Product Discovery. I also plan more mid-week articles in the form of a literature review or something interesting that I've read or listened to.
The idea for this week's article came from a passionate conversation with a few engineers on whether you can actually do proper product Discovery in Platform teams.
Firstly, what annoys me is using words like proper Discovery, real Discovery, etc. What does that even mean?
Secondly, the context you are in will determine whether or not you do any Product Discovery. Do you have a problem you want to solve? If yes, then great - odds are you can do Product Discovery. If no, then - no.
Do you work for an organisation that supports that and is willing to experiment? Yes. Great. Then, you can start doing some Product Discovery. If no, then this is going to be difficult.
While there have been tons and tons of materials written on it, it is as simple as described by Marty Cagan:
Discovery is about finding a solution that works – one that is usable, useful, and feasible - and only then is it about engineering.
I always go to either INSPIRED or his older Product Discovery articles when I feel stuck or need help.
So before planning half-baked releases and considering including discovery in the sprint, let's start small.
To make this exercise more relevant, we will frame a discovery approach using an example that can be found in Platform teams.
Problem Statement
Example: We are experiencing a core challenge within our Internal Developer Platform(IDP) team, where developers need more accessible access to comprehensive and up-to-date documentation. This gap hinders developer productivity, increases onboarding time, and adds cognitive load within the team.
We must address this problem to enhance our platform's usability, accelerate development, and ensure a more efficient onboarding process for new team members.
Note: This is an excellent point to look for some data and be able to back up some of these assumptions, but let's assume that the friction is there.
Coming up with a discovery plan
Your team
In his 2009 Article, Marty Cagan refers to this as the Core Discovery Team. In your IDP area, this would be the very minimum: yourself as the PM (leading on this), your EM, a tech lead/lead engineer, and either a content designer or someone who is very good at designing docs. Usually, you might not have this person, and that's okay too.
As PM or someone leading on this discovery, you have to ensure that this group of people is aligned with the problem statement and that they understand the value of trying to solve it. Ultimately, they are your core discovery team.
The Discovery Extended Team
Who will be supporting the team on their quest to discover? In this case, other engineers, such as a Principal or a Staff Engineer, can be interested. A guild if you have one internally. A designer, maybe. This list includes a function with a stake in solving this problem and knowledge about how best to solve it.
Stakeholders
First and foremost, you need support from someone senior in product and engineering. Beyond that, this list should also include people that you might want to get steer or feedback from
Users
Who are the users? In our case, these are the internal engineering teams.
Risks
What are the risks, and how do you plan to mitigate against them? In this example, it could be a lack of engagement from engineers, a lack of time to focus on this, a lack of understanding of the importance of a good wiki, etc.
User Research
You should research to understand exactly what parts of the documentation you can focus on first and the critical areas to cover. You can do this as a PM in partnership with the EM by simply talking to your engineers and looking at support requests and previous feedback.
Validation
How do you intend to test and validate the initial approach with the team? A simple idea would be to start a simple Confluence/Notion page and get active feedback.
Product Vision
Does this need a longer-term vision? Most likely, no, but it can be an enabler for the overall IDP vision.
Product Principles
Do you need to draft a set of product principles? Possibly. If you want large-scale adoption, you should have some agreements in place. For example:
All our docs should be written in an accessible way
All our docs should be easily discoverable
All our docs should be easy to update
Etc, etc
That concludes the plan. There was more on the original list, but I adapted it to our example here. Do give it a thorough read though! On SVPG, you can find an exhaustive list of articles on Product Discovery.
So you came up with a plan; what's next?
Once you are clear on the problem you want to solve and have this plan, you are halfway through. Then, you must decide what to build to validate some assumptions. The answer should very rarely be a product or a feature.
In our example, you can run a live prototype by spinning up GitHub pages or Confluence page. Or Notion. Whatever tool is available to you.
Next is thinking about how to track progress against this and measure success. This is more challenging.
In the documentation scenario, you can target an area first, test it with a group of engineers, and then roll it out to everyone.
Depending on how and where you store the docs, you can get some engagement metrics, but sending out some feedback forms or encouraging feedback directly is also a great idea.
Suppose your discovery is successful, and you find that more and more engineers are adopting docs in that specific area. Congratulations!
In that case, you can demonstrate the impact and spend more time building a fully-fledged product.
I picked the Documentation example because while it may seem trivial initially, I have always encountered this as a friction point. It's often overlooked and rarely treated as a product in its own right.
I've also had some fun preparing a visualisation of this whole article in a very high-level format:
Finally, in preparation and writing for this article, I have referenced Marty Cagan extensively because I find it easy to digest and highly relevant.
P.S: Not related to discovery but more on how to build great products here is also a great episode from
See ya next Friday!