Want to ship better and faster? Check your product management standard of excellence

Software organizations often lack the rigor of PM excellence that is well-established in engineering and design, and that creates a slow burn toward disaster. These adjacent disciplines have well-established checkpoints and review mechanisms to ensure quality of their output meets the organization’s standards. Builders are held accountable for delivering on time AND with quality. But what about product management?

Thanks for the drawing, DALL-E.

In my experience, poor to mid quality product requirements are the leading risk for releasing sub-par products or shipping late. To reduce that risk, we need product management excellence, not just engineering excellence. We need planning, customer insights, and effective levers.

Issue #1: Inadequate planning and standards

The #1 cause of shipping late? Starting late. While annoyingly basic, it’s true. Inadequate planning for every stage and iteration of a project means something will either be delivered late or with poor quality. And that means every other dependency is impacted.

Engineering teams excel at planning (even when estimates are wrong). There is a delivery plan (yes, even in “agile” … eye-roll…) that includes milestones for technical design and review, incremental use case estimating, code reviews, scrum demos, testing, and readiness dates. Importantly, these milestones correspond with the organization’s engineering standards of excellence (whether light or deeply defined), such as: unit test coverage, automated tests, performance targets, security testing, accessibility testing, and more. They are held accountable for achieving those milestones at expected quality.

Joke is mine. Art is DALL-E.

Many organizations move from big goal to requirements delivery. Throw in some KPIs and collaborative sessions if you’re lucky. That’s not a plan. A plan includes dates, milestones, and reviews prior to delivery. For example: customer research, problem validation, solution brief, requirements drafting, requirements finalization. Any decent organization will informally discuss these with cross-functional colleagues, but that skips product management quality control. Intra-disciplinary review of critical output is needed: a review from other PMs will identify high-quality output and help each other improve.

Define requirements excellence and PM delivery milestones, and hold PMs accountable to peers who know what high-quality looks like. Most of all: plan for it to actually take time on a calendar. #1 reason sited for not doing these things? “No time.” To create quality, you must start earlier than you used to.

Issue #2: Guessing about the customer problem

The most damning cause of poor requirements quality is a lack of customer understanding with depth and detail. PMs may have not allotted the time for it (new hires always feel this), they may be working under lack of direction (such as during a pivot), or they simply may not have the know-how to get the right information. “Shiny objects” attract guesswork, as well. Products cannot be built for scale or usability without the true customer problem defined.

Second-hand (or “proxy”) intel tends to be the fallback. Unfortunately, proxy information “misses the nuance,” yielding poorly defined or missing details. Yet that’s what teams are expected to design, build and validate, leading to more guessing, changes and delays down the chain of work.

As a product leader, when I see holes in the requirements, my first move is to uncover what the PM is missing about the customer and where they are getting their information. Product leaders must set and hold the bar on what customer insights are required in order to move forward. Do PMs know the minimum direct customer input expected to consider a requirement proven? Do they have a mechanism to acquire it?

Issue #3: Misunderstanding productivity levers

Productivity levers are things you can do to help ship faster and ship more than you did before. Often implemented them at functional level, the goal remains the same. Examples include using AI tools to speed coding, or building a design system to speed prototype and front-end production. The mistake I’ve seen repeatedly is assuming that quick and dirty requirements are a productivity lever — it’s quite the opposite.

If enough context is understood across all team members, then communicating high quality requirements can happen quickly. That’s not “quick and dirty,” that’s quick and clean. Both must be true for requirements to become a productivity lever. Clean requirements can be quick if they are planned and backed with customer intel — defined with 3 characteristics:

• Problem and solution separation: by separating these, the team is motivated to truly solve a problem for a customer, and may find more effective or efficient ways to deliver a desirable solution.
• Cross-functional contribution: to arrive at a well-crafted end product, minimally PM, design and engineering should collaborate to define the solution. Without collaboration, details, feasibility, and opportunities are either missed or require more calendar time to revise into requirements. And when requirements are revised too late, the designs, development and testing must also iterate, resulting in slower delivery. Or they are not revised, resulting in poor quality.
• Refined and consistently structured product requirements: sloppy writing is a reflection of sloppy thinking. Consider requirements much like code — garbage in, garbage out. There’s a syntax to follow, and a min bar for quality that can be refined through collaboration.

Build better, go faster.

Expectations from customers and executives will continue to increase. We will always need to deliver products that are better than before 🔥, and delivered faster than before 🚀.

1. Set quality standards for clean requirements
2. Build milestones (and time) for delivering them
3. Conduct reviews amongst product managers to get there
4. Keep it iterative and light to make it sustainable

At first employees may complain. It’s hard to do things well, and harder to change habits. But you will quickly begin to hear a decrease in cross-functional complaints because everyone begins to see it’s easier to be effective in their own job. Next, design iterations will be more substantial, based on how users work rather than what they need to do. Technical design iterations are will become less frequent, based on system maturity rather than feature misunderstanding. And finally, customers will be happier, because they see immediate return for trusting you to give them a solution that works.