In pursuit of the team Purpose, some tasks a team undertakes are relatively straightforward (can be stories with no further discovery), a lot of tasks are more open ended. "We're not getting enough customers." "We need some way to be unique to penetrate this market."
In this section, I detail some different methods and thought patterns I use when discovering and evaluating new opportunities.
Like with Roadmaps, the best opportunity documentation is the one at the company that is best adhered to. I will not be prescriptive in documentation formats, since this very much will need to be adapted to each and every situation. I will detail more about how I think about each kind of format and more of the thinking patterns that fuel different discovery/opportunity assessment formats.
<aside> ✨
Opportunity Documentation is one of the things that I think can be made more efficient through working with an LLM to synthesize information and place it into the agreed-upon Opportunity Document format.
</aside>
To me, thinking in Outcomes is the meat of assessing new opportunities. It’s the “So What?” meat in the Product Manager sandwich. While outputs are usually cool, it’s a common trench (especially in B2B) to be stuck in what you get out of development work, not why you get there.
Some tips I use to center the conversation to Outcomes:
A good Purpose will center on outcomes that move the business forward.
Honestly, this buzzword makes me feel like Steve Jobs. And not in the super-innovative way, but in the daily-turtlenecks-look-uncomfortable way. But I think it's good to approach problems not by its most immediate solution, but to also ask "is this ambitious enough?"
Companies, from my understanding, don't hire technical teams for our Zoom jokes and ping pong skills. We are all hired and paid above-average wages because technology has the unique ability to make our user's lives easier, to take the burden out of regular, mundane tasks. So, when thinking about how to solve problems, it's important to not just blindly copy the world and competitors around the idea, but truly think about how to understand next-level problem solving. I'd continue, but that turtleneck is getting itchy again.
My personal challenge lies in how to factor 10x thinking while making it genuine. My way of doing this is to proportion my X to the conversation. There's no need to bring up how to "move the needle" in a bug review meeting, but there is a need to spend an equal amount of time in that bug review meeting to understand how we can create a more stable platform without bugs. So maybe 0.5x or 1xing the technology there. And as a product manager is the protector of the Purpose, it's absolutely essential in vision-/mission-defining conversations to communicate how ambitious (ie how many X's) large initiatives are. For example, when setting a roadmap and communicating that roadmap, it's important to center back on the purpose and how much this purpose is looking to scale the business. It's important, as the protector of the Purpose, to know what similar purposes or initiatives might also have larger impact and why they would be good or bad ideas. It’s important to have strategy discussions on how the purpose may be informed or shifted based on new information.
Technology today exists in the ecosystem of other technologies. It’s very rare to come across an entirely homegrown piece of software, deployed to a server that exists in the office basement. Not a particularly scalable or sellable one at least.
So, there’s a conundrum. Do you build a new thing from scratch? Or find someone who is already doing this to partner/purchase their services?