The One Thing Most Product Managers Get Wrong

Most product management in the world is weak because it is focused almost exclusively on the customer/market and not enough on the important technical implementation decisions.  A great product needs both.

So great product managers need to be very technical themselves and make important technical decisions.  This doesn’t take away from the importance of knowing your customer and solving a valuable problem for them. Achieving a good product-market fit is always necessary for great products, it's just not enough on its own.

What's Wrong with Most Product Management Structures?

In most companies, this is divided across 2 different roles: 

1. Non-technical product managers who create a Marketing Requirements Doc (MRD) that is tossed over a wall to engineering
2. Technical software architects who sometimes create a Product Requirement Doc (PRDs) in the form of a big document (that usually doesn’t focus on the core data structures and algorithms) or user stories that don’t even try to make important technical decisions up front.

Architects have a fraction of the context required to make great decisions, and the scope is often disconnected from the technical implementation.  Worse, what happens most often is that engineering starts creating Agile user stories devoid of important technical decisions, and developers just start coding.  

This is how crummy software happens, and why all senior Product Managers should be Technical Product Managers.  They have to be great at making important technical decisions that are directly connected to the product’s core functionality. 

Product Managers should be Strategic, Not Tactical

At most of Crossover's client companies, Technical Product Managers create a work product called a Prod2.  The objective of a Prod2 Spec is to identify and make the most Important Technical Decisions (ITDs) for a product.

An example we often use is to imagine you have just purchased a large, old, building.  You have ambitious plans, so you contact an architect and start talking about your dreams… how you want to add space, that you are thinking of putting a huge swimming pool on a high floor, and that you want to do some interior restoration and upgrades.  What’s the first thing the architect says?  That she wants to see the building’s current plans.  And she isn’t talking about the very detailed construction-level plans; she wants to know the fundamental design decisions that were taken in the past and understand the reasoning behind them.  She wants to understand that the foundation was done in a certain way because the building is in a flood plain.  She wants to know that the building weight is carried through load-bearing walls and not through a structural skeleton.   She wants to understand why certain materials were used and what their current limits are.  With this knowledge, an architect can make a set of high-impact decisions that achieve some goal.

After the big picture decisions are documented and approved, a more detailed set of plans can be created.  Construction companies build the buildings, not Architects.  And construction companies need construction-ready plans.  Blueprints are created to lay out the final details of every wiring conduit, light fixture, plumbing line, window and door dimensions, etc, but they work within the important decisions made by the architect.

In our world, Prod2 specs are sent to a separate team that turns them into the software equivalent of blueprints, called Prod1s.  Prod1 specs follow the ITDs outlined in a Prod2, and make the next level of technical specification.  In addition to further implementation details, they also define the acceptance criteria that will be used to accept/reject smaller units of progress from the engineering team.

Prod2s Answer the Important Questions

In the software domain, it is all about getting past the surface and deep into the important technical decisions of a product.  Great Prod2 specs answer questions like:

• What is the most important functionality of the app?
• What are the core data structures used by the app?  Why were they chosen?  How are they mapped or applied to the domain of the problem?  What were the tradeoffs or alternatives?
• Are there any important or valuable algorithms?  What insights led to choosing them?
• Are important third-party components/technologies used?  Why were they selected?  Are they the right ones today?  Were they ever?
• Are there any components of the system that create valued and differentiated capability relative to competitors?  Why?  (we call this “TechDiff”)
• What was the design and reasoning behind the important internal and external APIs?
• Identify and explain the rationale behind important technical dependencies or limitations this product has.  Are they real or artificial?
• Can the product be broken down logically into smaller, more manageable components?  Are there well-defined interfaces, or layers, between those components?  Or are they all interconnected?
• What is the critical opinion of a fresh set of eyes when looking at old decisions?  Are there architecture or design anti-patterns present in the fundamental technical decisions?
• If making a non-trivial change to a product, what is the right sequence of milestones we should follow, and why?

How to Define Decisions as a Unit of Work

The most fundamental unit of work our CTOs create is a technical decision.

We call them Important Technical Decisions (ITDs) because:

I - They need to be Important.  These specs must make the decisions most essential to the strategy of the product, and not be bogged down with decisions far from the product’s core.

T - They need to be Technical.  UIs and Use Cases are rarely the most important thing for a product’s success.  We want to make decisions that are deeply technical in nature and define the important parameters that builders of the software need to get right.

D - They need to be Decisive and Documented.  Teams can’t scale unless these decisions are written down - the knowledge can’t only live in some expert’s head.  Decisions need to be bold - this is no place for consultants who give the pros/cons of many different approaches but fail to pick a path - we make decisions that remove ambiguity and options, not create more choices.  We are unafraid to state our opinions strongly and are willing to change them if presented with good arguments when reviewed.  Finally, good decisions require the reasoning and logic which created them.  CTOs always “show their work” - the facts, logic, and assumptions they used to make their decisions.  Sometimes we change our final decisions because the SME or expert points out a flaw in our logic or our assumptions. We value clear and correct decision-making over the final answer (because the former leads to the latter).

How does a CTO decide what’s Important? There are a few strategies:

1. Most applications can be explained in terms of Inputs, Outputs and the work the product performs to convert Input into Output. Consider the transformation of Inputs into Outputs. Are the decisions related to that? If not, then the decision is not core to the product.
2. Imagine you have limited space to communicate the decisions to your engineering team. You trust your engineers to make good decisions, but there are some that if made differently then how you would make them, would cause you to reject their work. What you slot into this limited space are the most Important decisions.
3. The decisions are specific to the product or domain, not generic standards that an architect applies to all products they work on. 

What Should Companies Change?

Companies that value customer experience need to understand the role that technical execution plays in creating a great product, and therefore hire strong technical minds for all product management positions – ensuring that the customer experience isn't undermined by poor technical decisions.

What Should Product Managers Change?

Normalize the documentation of Important Technical Decisions (ITDs) for all products. This will arm colleagues and future teams with full knowledge of not just how the product is built, but the context for why various alternatives were rejected. This saves valuable time and budget from being wasted by flip-flop decisions or pursuing ideas that have already been proven deficient.