paint-brush
Minimum Viable Controlby@danielfschmidt
623 reads
623 reads

Minimum Viable Control

by DanielDecember 21st, 2018
Read on Terminal Reader
Read this story w/o Javascript
tldt arrow

Too Long; Didn't Read

<strong>Introduction</strong>

Coin Mentioned

Mention Thumbnail
featured image - Minimum Viable Control
Daniel HackerNoon profile picture

A Framework for Product Leadership

Introduction

Making the transition from hands-on product management to leading a PM team can be disorienting. On the one hand, if you get overly involved with projects, you’ll stifle the creativity of the team. And it’s unsustainable to be on top of every detail, especially with products that require heavy domain knowledge. On the other hand, if you’re too hands-off, you risk allowing product changes that don’t meet your standards or big picture business objectives.

More than once I’ve seen product leaders, unable to grasp their role, get arbitrarily involved in design decisions, seemingly out of a need to put their own “stamp” on the product. Behavior like this demoralizes the team and creates a low value hoop in the product delivery cycle.

But how far can you step back? The key is minimum viable control (MVC). The essence of MVC is managing the structure of your team’s process without controlling the substance of launches.

The Elements of MVC

I. A sound learning process

As a manager of PMs, as much as possible, I stay away from questioning the ideas and designs that come through the development cycle. However, I need to feel confident that each change is being sufficiently tested, validated, and evaluated post-launch.

A sound learning process requires teaching your PMs to have a scientific and paranoid mindset. PMs should relentlessly pick apart and test each assumption underpinning product directions. They should be paranoid in imagining everything that might go wrong with each product change and take necessary measures (e.g., through A/B testing) to avoid tanking business metrics.

I created Double-Loop, in part, so teams can quantify the rigor of their learning process. With Double-Loop we can measure and continually improve how many of our launches have clear hypotheses and results.

II: Cross-functional integration

As I discuss in The Product Management Triangle, near to the essence of product management is synthesizing the activities of the diverse set contributors spanning engineering, design, marketing, sales, and customer support. As a product leader, you must ensure that your team is incorporating inputs from across the organization in their ideation and prioritization process.

Conversely, your PMs should treat internal communication with the same care as external communication. When sharing a product update or strategy, PMs must tailor their medium and message to the unique psychology of their cross-functional counterparts. For example, after a launch, your team may need to communicate different information to marketing than they do to customer support.

As the product leader, you must create the bidirectional pipes of communication between all the people who touch the product. Your job is not to oversee what content goes through the pipes. Instead, it’s to make sure that the right pipes exist, unobstructed

III. Top-down integration

You have better visibility than your PMs into the big picture of the business. You’re more exposed to the workings of the board, dynamics of the executive team, and financial milestones. In contrast, your PMs should know more than you do about the functional workings of their product area and the nuances of their domains.

Your job is to ensure that the work of your team reflects the big picture reality without dictating what your PMs build to achieve the goals. Objectives and key results (OKRs), for example, serve as a nice non-prescriptive interface with overarching business direction. The best formed OKRs provide stable criteria for what success looks like while not constraining tactics. Without something like OKRs in place, your team will feel like they’re floating without a foundation to stand on.

Top-down integration must go both ways. While your team’s work must reflect objectives from up high, the learning of your team should influence how the executive team thinks. Your team must abstract and communicate the results of their launches in a format that is clear from way up in the sky. Otherwise, antiquated strategies will keep raining down down.

Conclusion

Maintaining a sound learning process, cross-functional integration, and top-down integration is a full time job that requires surprisingly little knowledge of the details of your product. In a sense, the product leader provides value as an outside observer who can objectively monitor how their team is working without micromanaging what they’re doing.

By staying at the level of MVC, you can achieve the best of many worlds. Your team will be unleashed to solve problems and seize opportunities as they see fit. Embedding your PMs in a rich network of horizontal and vertical information flow will fill their brains with the context to make wise decisions. And the scientific process of testing and experimentation will make their failures safe, both financially and psychologically.