medium.com - My preferred product management techniques and frameworks (for the internal platform product…

Tip

A structured toolkit for internal platform PMs, emphasizing direct observation (“go and see”) and telemetry for discovery. It advocates for specific frameworks like DIBBs for strategy, “Now-Next-Later” for roadmapping, and a “Think It-Build It-Ship It-Tweak It” lifecycle to ensure continuous learning and alignment across the organization.

Sitemap

Customer/Problem Discovery

How do we understand reality and the relevant challenges?

Understand reality through direct observation and product telemetry

• Direct observation in context. Also known as genchi genbutsu, go and see, ” get out of the building ”, or in this case “get out of your department”. As an internal platform product manager, you nominally have access to your entire customer population. Take advantage of it.
• Product telemetry. Instrument the platform products so you can collect data on user behavior.

The combination of direct observation in context and product telemetry is what I would consider the best approach.

• Talk to everyone. This could be with 1:1s or with small groups. This works especially well with more reflective engineers. Others you may need to tease out over time. Talking to everyone has the benefit of feeling more collaborative (involvement increases commitment) but is extremely expensive as an ongoing practice. It may still be worthwhile as an initial one-off to develop broad relationships. Ongoing random sampling might be more practical though I’ve never actually tried this. What I have done is ask leaders to nominate representatives, which is also useful socio-politically.
• I don’t find surveys to be that useful unless response rates are very high and you almost always have to follow-up to understand specifics. The best tooling I’ve encountered so far for this is DX with their “auto nag” (my name for it) capabilities.

If we don’t want to constantly relearn everything, we need to organize the data and insights we get from discovery activities. In other words, we need a research repository. I don’t really have a strong opinion on the specific appproach to research repositories beyond having one place to search, a standard format, versioning, and distinguishing data from insights. Most of what I’ve seen has been Confluence, Sharepoint, or custom web sites.

Solution Discovery

How do we expand our toolbox and increase optionality?

How do we expand our toolbox and increase optionality?

• Keep up with industry news. Newsletters, social media, blogs, Slack and Discord forums, etc.
• Learn from peers. Catch up with former colleagues, people you’ve met at conferences, etc. If you see an interesting talk or read an interesting article, consider reaching out and asking for a “behind-the-scenes” chat. People filter what they share in public but are generally more willing to share details in private.
• Attend events. User groups, webinars, and conferences.
• Learn from partners. Treat what they say with a grain of salt but at least you’ll learn about new features for their products or new techniques they’re trying.
• Experiment. Spikes, hackathons, etc.
• Read. Both to learn about new technologies and techniques but also to refresh and reinforce fundamentals.
• Take courses. Coursera, LinkedIn Learning, in-person(!), etc.
• Learn from colleagues. Share what you learn and encourage others to do the same.

Product Strategy

What are the specific challenges we should focus on? How should we address them?

What are the specific challenges we should focus on? How should we address them?

I like Richard Rumelt’s way of approaching strategy as problem-solving. See Good Strategy Bad Strategy and The Crux.

More specifically:

• Spotify’s DIBBs product strategy framework | by Jason Yip | Medium
• From Gut to Plan: The Thoughtful Execution Framework | Spotify Design
• And A3 thinking in general

Product Vision

What does success look like? How do we communicate it?

What does success look like? How do we communicate it?

If people can’t picture it, by definition, it’s not a vision. This is not just about arguing definitions. It’s motivating to have a destination that people can picture. Calling an abstract mission a “vision” doesn’t somehow magically create this effect.

The best way to communicate a vision is to show something.

Typically, this means a prototype, like a Wizard of Oz MVP or a series of wireframes to lay out the target user journey. The idea is not to describe all the details to build it but to convey the essence of what we’re aiming for. That is, a vision for the future.

Get Jason Yip’s Stories in Your Inbox

Join Medium for free to get updates from this writer.

A Business Model Canvas or similar can be useful to highlight the different activities and relationships that may be required in this future vision.

Product Roadmaps

What’s the path toward where we want to go?

What’s the path toward where we want to go?

Extracted and modified from Product roadmaps: focus, confidence, coordination | by Jason Yip | Medium:

Now Next Later at a Minimum

Now Next Later roadmap

The simplest roadmap that basically works is grouping items into three buckets:

1. What we should work on Now.
2. What we should work on Next.
3. What we should work on Later, that is, what we shouldn’t worry too much about right now.

Now Next Later is useful for addressing focus; it is not as useful if people are not confident with the logical path to the product vision, nor is it as useful to help with timing for coordination.

Rolling Wave: Current Quarter, Current +1, Current +2 and +3

Adding a rough timeline is the next step above Now Next Later.

For example, Q1, Q2, H2, and then adding a new quarter to the end every quarter.

Rolling wave roadmap

User Story Map, or Something like It, if You Can

User Story Map as Roadmap

My general preference is to use User Story Maps or similar. User Story Maps are useful to create focus, clarify the logical path to a product vision, and helps with coordinating timing in terms of releases.

Opportunity / Questions Backlog if there Are Too Many Unknowns

In situations whether there are too many unknowns, it’s generally not practical to try to create User Story Maps. Instead, the product roadmap ends up looking more like a sequence of questions or a list of opportunities to prioritise.

See also:

• Product Roadmaps Relaunched

Alignment

How do we ensure everyone’s on board with what we plan to do?

How do we ensure everyone’s on board with what we plan to do?

• Talk to everyone in 1:1s or small groups to get their unfiltered feedback on the plan. This is also known as catchball, shuttle diplomacy, or nemawashi. Don’t try this with large groups unless you want to avoid getting actual feedback.
• Everyone regularly publishing what they’re doing. For example, everyone publishing weekly email, Slack, or blog updates. This is difficult to sustain unless the most powerful and influential people buy into it.

See also Prepare the Ground, Then Integrate: an integration pattern for aligning humans | by Jason Yip | Medium.

Metrics

How do we assess our progress and beliefs?

How do we assess our progress and beliefs?

• Goal Question Metric (GQM). What goals are we trying to accomplish? What questions indicate progress or validation? What do we measure to answer the questions?
• Goals Signals Metrics. What goals are we trying to accomplish? What signals indicates progress toward the goals? What effectively measures the signals?
• Output → Outcomes → Impact. Outputs are the capabilities and features we believe will lead to the outcomes we want. Outcomes areobservable changes in user behavior that we believe will lead to impact. Impact is the value returned to the organization (e.g., increased revenue, reduced costs, etc.).

Product Life Cycle

How do we structure our work for learning?

Think It Build It Ship It Tweak It

I still like Think It → Build It → Ship It → Tweak It. Use an initial discovery team to produce a prototype and product definition; expand to a build team to produce the first MVP release to real users; progressively roll out to all users; continuously improving the product until the next round of discovery or exit.

Some rights reserved

1.3K following

Senior Manager Infrastructure and Platform Engineering at Grainger. Extreme Programming, Agile, Lean guy. Ex-Spotify, ex-ThoughtWorks, ex-CruiseControl