Continuous Alignment of Product Management

There’s a startup product metaphor that bugs me. Your product is a rocket, and if your targeting at launch is 1% off — you miss the moon by 4,000 miles! The thing is products, rockets and targeting don’t work that way. I have resorted to a cartoon to explain:

In Products are Conversations I explained that great products come from conversations with customers and internal stakeholders. In this post, I’ll suggest how you can improve the Product Management process of Continuous Alignment with internal stakeholders towards envisioned outcomes.

In some ways, Product Management used to be easier. You’d gain customer requirements, document them in a Product Requirements Document, throw the spec over the wall, accept a Technical Requirements Document that was in alignment. Then drive development down a waterfall and months later this product which was perfectly aligned with what customers and stakeholders specified would ship.

Of course we all know that story and how it failed. Because things change. Along came agile development, which embraced change and the chance to learn. Design, development and implementation overlapped with small pieces of agreement in faster cycles. In fact, we got really darn good at it. High performing agile teams can move a story through design, development and implementation with awesome velocity, tool and process discipline. And move on to the next one with little to regret.

But when you zoom out from above these atomic particles, you see a different picture. Even the best performing teams have trouble shipping what customers actually want. Team members on the front lines with customers don’t feel advocacy of customer problems is being heard and acted upon. What is planned and shipped feels opaque and out of synch to the less agile parts of the organization.

This lack of alignment says something fundamental about the nature of work, the products we create. It isn’t a problem confined to Product Management. In fact, it is that problems can’t be confined.

Continuous Alignment

In most organizations today, alignment still happens through Push mechanisms. From an executive planning process, and plan with the way things should be when is pushed into the organization. Everyone has to get behind the plan.

Don’t get me wrong, there is extreme value in making plans and roadmaps. It’s an exercise in thinking through the vision, landscape and resources that creates shared understanding, assumptions and decided goals. That exercise, despite the best dysfunctions of teams, aligns the participants and creates artifacts that share that understanding of strategy out to the broader team for execution.

Leading agile companies set the vision, goals and measures. Their plans are a view of desired outcomes and impacts. Their roadmaps are thematic, they make maps, but all plans and assumptions are subject to change. They value rapid iteration and the speed of decisions. In the shift from push to pull, making alignment a Pull function for product requires shifts in tools, practices and cultural philosophies.

The lynchpin is one practice — how does this plan change?

If there is an exception to a process, how is it escalated, how does the right group of people rapidly assemble, not just to fix the problem, but to learn from it? Exceptions, or problems, come from a change in the environment the process and organization was not designed to process. A change that is an opportunity. And that’s not how most organizations think of problems. Mostly they are a pejorative, a chore to get done while time is tracked.

Leading companies put tools and processes in place. At least for the known knowns and known unknowns. The unknowns unknowns are the realm of having a great team with muscle memory from responding to prior unknown unknowns.

For example, for customer problems there are support escalation processes that involve cross-functional stakeholders to resolve the exception and encapsulate the learning. If you are a PM involved in this kind of process, your role in this process isn’t just as an expert that might have the answer for swift resolution. You’re there to gain the learning, help them see how it fits into priorities and plans — and in the process help people understand the opportunity to celebrate problems, and innovate beyond not having the problem happen again.

Or for example, creating an Idea Board (shameless plug) to source problems from sales, sales engineering, customer success and support. They triage and prioritize them, assemble their experts to craft solutions to problems, to put them into plans and action. The original context is captured and stakeholders are automatically kept in synch. These new problems continuously contest the roadmap, so there’s less of a gap in prioritizing the backlog for the next iteration, the most valuable things are made visible, and prioritization goes forth with ruthless abandon.

We launched. Now what?

After you ship is when you learn. That’s when your hypothesis can be tested, by how the market and communities react. Be ready for this moment, have your hypothesis of outcome and impact on hand, instrumentation in place, and get ready for conversations with customers. What you decided to ship will likely fail. And what matters is what you learn and do next.

Thomas Vander Wal observes that in the research, prioritization and planning process you develop good solutions that aren’t chosen to ship are great opportunities, and how the team learns to decide is as important as what they decide:

The gold is often in what you initially decided not to do, but is well researched and thought through. This often sets really good product teams and groups apart from others. Every product iterates when it gets tested by real users and or when released for wider use.

Learning from what you chose, what worked and didn’t work, but also what was iterated to is helpful. Understanding why one direction was chosen that didn’t work optimally is good to know, not to assign blame, but to use that in consideration for the next rounds.

The more the team practices making responsive action and learning, towards proactive goals, the more resilient they are to thrive amidst accelerating change.

Good agile practices and cultural philosophies with great customer engagement will get you a quality product, but it is easy to lose sight in those iteration of the longer term goal. The moon, if you will.

To get to the goal, constantly check against the vision, mission, objective or north star metric. Whenever something has changed that could change the plan. And with the readiness to change plans by celebrating problems and consciously understanding how the team decides to change.

The Lines Between You Must Align

Esko Kilpi observes that (industrial era) management a wrought efficiencies from division of labor. Managers divide labor into activities, or jobs, and optimize performance within those activities. Within these boxes we’ve realized all the productivity gains we can. He points out the opportunity is is the lines between those boxes. How activities are connected and aligned.

The next phase of productivity gains will come from continuous alignment within and beyond the firm. For Product Management, this means mind the product, but also mind the gaps. Product organizations that realize and invest in it will not only move forward together, but make better decisions to create the products customers want. And continuous alignment with Customers and Stakeholders is fundamentally a collaboration problem.

Products Are Conversations

Our hypothesis is Products are Conversations. In our research, we found that the biggest problem in Product Management is creating and executing a roadmap that customers actually want. And in talking to over 50 product leads we gained some interesting insights into this problem.

There are a lot of tools and processes for the Product Owner part of the role. Think Jira. But not a lot for the core function of Product Management — setting the vision, being close to customers to gain insight, prioritize and decide on their behalf, and continuous alignment of stakeholders. The tools that seek to support this function largely originate from Project Management and trend towards Gantt Chart planning of what should happen. They are used by a few to make and publish roadmaps for many.

Meanwhile alignment is episodically orchestrated in Slack channels, email and meetings. Product Managers get by because they have great organization skills and communication discipline. But they lack a collaborative system that supports continuous alignment, and the automation that enables the function to scale.

Awesome Icons by Creative Stall from the Noun Project under a Creative Commons license. Thank you. Remaindered links: A silly example of the 1% mistake myth, What % of time was the moon mission on the right trajectory?, Scariest Moments of the Moon Landing, A Checklist Error Didn’t Derail the Moon Landing.

Continuous Alignment of Product Management was originally published in Hacker Noon on Medium, where people are continuing the conversation by highlighting and responding to this story.