3 Diamond Product Process

Product Management process has always been a bit messy and ill-defined.  There are numerous artifacts and activities that most will generally agree take place, but sometimes these are missed and it is rarely clear whose responsibility they are, or in what order they should flow.  To that end, I wanted to map out a process that I think makes sense, and that incorporates the major activities and artifacts that are part of more Product teams work.

I started by leveraging the Double Diamond model from Design Thinking.  I really like this model because it captures the nuance of divergent and convergent thinking which also makes sense here.  In divergent thinking, we’re starting with input and exploding it out to all of its possibilities (brainstorming). With Convergence, we filter and synthesize those many pieces back down into a distilled output, that reflects those many possibilities that we identified.  Take the Product Strategy diamond for example (the first diamond, shown above) – we take the Product Charter as input from Business about what we’ve been funded to do. We then go deep on market research to understand the customers we’re serving, the capabilities we can leverage, and the competitive landscape we must find a market position within.  Once we’ve completed that divergent research, we distill (converge) all of that into a concise Product Vision that will drive our subsequent planning activities.

The same approach is implied for each of the subsequent diamonds. In Planning, we ideate on all the possible projects that we’ll then score against our objectives, which helps to prioritize what we’ll work on.  And in the Product Development diamond, the team conducts user research and prototyping exercises, in order to determine how to design the solution we will eventually release.

Process Stages 

For reference, here is a summary of each of the major process stages (aka each diamond): 

i. Opportunity Discovery –In response to the product charter from business, we research the 3C’s to understand the most impactful customers, the available technical capabilities and the competitive landscape we must position and differentiate our product in. The outcome of this process is a definition of a product vision and the objectives that will govern planning.

• • Market Research
  • Internal Analysis
  • Differentiated Value
  • Product Vision

ii. Product Planning – Once the strategy is clear, planning is about identifying what to build, determining the structures by which to organize those efforts, ideating possible efforts and then prioritizing them as to how they align ultimately culminating in a roadmap that will govern product development.

• • Planning Themes
  • Objectives & KPIs
  • Project Ideation
  • Teams/Missions
  • Prioritization
  • Product Roadmap

iii. Product Development – Feature projects and technical enablers (that will unlock future features) are the deliverables of product development. Starting with product requirements, the cross-functional teams work at this level to conduct user research, prototype solutions, design and development, test and iterate those solutions for the desired outcome.

• • Requirements
  • Usability Research
  • Prototyping
  • Development
  • Release Plan

Process Artifacts

Between each process state (diamond), are connectors that reflect th major artifacts that begin and conclude each state.  Below is a brief description of each:

• Product Charter – This the definition from Business or the Product Council about exactly what they’re funding, what resources are being made available, and what outputs are expected from that investment. This is what kicks off product strategy. Read more →
• Product Vision – The product vision is a concise statement that articulates what is being built, who it is for, why it is valuable, and how it will be differentiated.  Read more →
• Product Roadmap – The plan for how the vision will be realized with tangible projects, to show how the provided resources will be applied to achieve the strategy.
• Release Plan – As the working teams, (aka “feature teams”) design and develop reach feature they may define a release plan (aka ‘delivery plan’) that indicates when and how the feature will be deployed and launched.

Another Way of Looking At It

Below is a more flowing illustration of the same conceptual model.  The process flows top-down, beginning with market research and identification of market opportunities.  Then in planning, we ideate and merge those ideas with opportunities to determine priorities.  Those priorities inform the roadmap (aka plan).  The feature projects on the roadmap are then broken down into requirements for design & development, and a release plan finally indicates how/when those features will be delivered.

Planning Alignment

In this last view, I think it is helpful to articulate all of the planning objects and how they relate (think object-oriented design for this one).  The vision is the originating object that responds to the business charter. Objectives are derived to support the vision. Themes and major initiatives are then identified and mapped to those objectives.  Feature projects are ideated for how to implement those themes.  Each feature project is comprised of requirements (aka User Stories in Agile speak), and finally, the actual work tasks are broken out for each requirement – those are grayed out here since those work activities are owned by the team and merely respond to the plan, rather than being part of it.

Conclusion

Hopefully, this provides a useful model that teams can implement and build a structure around.  What I’ve come to realize over the years, is that alignment is the most important outcome we’re trying to achieve in Product leadership. That means aligning up to Business strategy, to the sides with stakeholders and their respective functional strategies, as well as down to the team to ensure they understand the decision-making fabric, where they fit in and how to effectively contribute, which helps to reduce overlap and misplaced expectations that sometimes come with being the ‘CEO of the Product’. In my next article, I’ll discuss optimal team architecture, which this in place as a foundation.