Simplifying product's complexities

To reinforce product fundamentals, just PUSH ME

This work we call product can send practitioners spinning in all directions. Today we need to conduct research with key customers; tomorrow we’ll be collaborating with developers; next we’ll be getting deep into a prototype for a new market segment; all the while we’ll be communicating with sales, engaging with customer service, and updating our senior leaders.

Though we might grumble, most product pros actually appreciate our domain’s complexity. Product managers are by nature curious polymaths, and we love working both wide and deep. But all that complexity, all that daily messiness, can disrupt our focus on the basics of the work. In response, product leaders have developed and shared countless frameworks and tools. There is Kano and GIST and Opportunity Solution Trees and North Stars and RICE and DHM and on and on.

To reinforce the basics and organize my product thinking, I use a simple, homemade mnemonic device: PUSH ME. That’s two simple words, comprising six letters, which represent four short sentences.

1. Where to Begin: P-U-
Start in the Problem space, with Users.

The P and U at the start of PUSH ME signifies that the problems or opportunities in your market come before any solution, any software, any service. And those problems are experienced by our product’s users. Who are the people we are best equipped to serve? What problems can our product solve for them? When I’ve led products and product teams, I’ve often said I may report to my boss, but I work for my product’s users. The users tell you or teach you what to do next.

2. How to discover and deliver: S-H-
Discover and deliver Solutions to test Hypotheses.

The S and H reminds us that solutions are best thought of as hypotheses. This solutions work comes after we understand the problem and our users or customers. But don’t fall in love with possible solutions—they’re all hypotheses to test. This principle forces us to start from a posture of humility, and to engage in discovery before delivery. At your beginning, there’s a lot you don’t know, but you have ideas. Approach them with the rigor and curiosity of a scientist. Certainty is tempting but dangerous.

3. How to evaluate success: M-
Measure outcomes to learn, then respond.

You’ll evaluate your experimentation through thoughtful measurement, the M in PUSH ME. And don’t just measure key business metrics like revenue, retention, and customers, as important as those are. Those are lagging indicators. Build a metrics framework based on outcomes for your customer and your business. Celebrate when you produce results, not when you merely complete work.

4. How to organize and fund the work: E. 
Empower a team.

PUSH ME’s final letter, E, reinforces that to build a great product, a business should assemble and empower a strong team. The team, not the project, is the mechanism that’s responsible for delivering value. Successful product teams have a variety of skills. They are aligned on their vision. They have access to users and data. They trust one another. They start together and they engage in activities together. Ideally, teams, not scope, are what the business funds.

In this month’s Pollinator, we share one resource for each of these four PUSH ME principles. If you recommend other articles, please share them with the Pollinator community.

In some ways, PUSH ME is entirely unnecessary. The product world surely does not need another framework or corny acronym. And PUSH ME doesn’t include any cool techniques or beautiful artifacts. It simply reinforces product’s basics. Product can get complicated awfully quickly. That’s why we need to remember the fundamentals. PUSH ME pushes me to do just that.

On to the Garden,

Around the Garden

What’s your problem?

Check it out: Start with the Problem Space, Sondra Orozco, Academy of Product Management

Sondra Orozco’s article from Academy of Product Management is a strong primer on not just techniques but mindsets for PUSH ME’s first sentence: Start in the problem space, with your users. Here’s how she succinctly describes the approach of product managers and teams working in this mode:

“When you’re in the problem space: you’re exploring, inquiring, and developing an understanding of the issue; you’re not actively trying to fix it.” 

Sondra Orozsco

Orozco also includes practical techniques for product managers and teams working in the problem space, including our favorite tactic: talking to customers, relentlessly.

“Step one: Talk to your customers! Do this often so you’re always learning about customer needs.”

Sondra Orozaco

Experiment like a boss

Check it out: How to Design Experiments for Your Product, Richard Holmes, Department of Product

Richard Holmes from Department of Product offers a comprehensive summary of experiment design for product managers. It’s a great article for product managers wrestling with the second principle of PUSH ME: Discover and deliver solutions to test hypotheses.

We appreciate the depth and rigor of Holmes’s advice. He doesn’t just advise you to experiment; he explains how to do so with the discipline and curiosity of a scientist.

“Experiments should be run as genuine pieces of scientific, investigative work to try and find insights into problems and answers to interesting questions which help you to achieve your goals…Experiments should supplement, not supplant your product OKRs, goals, and roadmaps. They are a tool which assist you along the path to achieving goals and have little inherent value to your users by themselves…Armed with results from a genuinely insightful experiment, you can inform your roadmap, your team and your stakeholders and reassess your goals with the insights you’ve gained.”

Richard Holmes

Helpfully, he walks through the stages of experiment design in detail:

1. Ask questions and generate ideas

2. Create a testable hypothesis

3. Conduct your experiment

4. Communicate your results

5. Prioritise your results

Richard Holmes’s Experimentation Steps

Finally, he even includes examples of the types of variables you might want to test, depending on the problem you’re trying to solve. For example, if you’re working on problems with lead generation, you might experiment with marketing channels, landing page elements, copy, or CTA buttons.

Measure for measure

Check it out: Measuring Everything that matters, with Doug Hubbard, YouTube, Clearer Thinking, with host Spencer Greenberg

At SDG, lately we’ve been grooving on Douglas Hubbard’s How to Measure Anything, a classic business and economics book about measurement, risk, and probability. Hubbard’s books and thinking are great accompaniments to the M in PUSH ME: Measure to learn, then respond.

Hubbard isn’t directly concerned with product management; most of his work focuses on applied economics and risk management, with applications in insurance or security. Still, Pollinator readers and other astute product pros will surely see how the methods he describes apply to the product decisions that a product manager and team wrestle with.

This video (which is actually an audio-only track, perfect for background listening) is a recent discussion between Hubbard and Spencer Greenberg, the host of the Clearer Thinking Youtube channel. There are dozens of interviews with Hubbard available online, but we think Clearer Thinking’s offers a great overview of Hubbard’s insights into measurement. Among our favorite moments is when Hubbard explains the meta-measurement involved in evaluating our own decision-making skill:

“A lot of this comes from measuring your own skill at decision-making…probably one of the most important measurements you can make in your life…it's kind of a meta measurement…

That's going to tell you, among other things, what are the conditions under which I'm a better decision-maker? Are there methods that help me make better decisions? That includes things like buying a house or a car or accepting a job.

People rely on their guts. Well people's guts have been measured quite a lot and it's really not nearly as good as people think. People are consistently better if they rely at least in part if not entirely on some quantitative assistance to their decision making.“

Douglas Hubbard

By the way, Hubbard Decision Research, Douglas Hubbard’s consulting and research business, also maintains a YouTube channel. That channel features brief clips of Doug Hubbard himself talking about risk, measurement, and his Applied Information Economics methodology. Find the channel here: Hubbard Decision Research YouTube Channel 

Root, root, root for the home team

Check it out: Real Talk about Empowered vs. Feature Product Teams | Chris Jones (SVPG), from Creator Economy with Peter Yang

We’ve said it before: an effective, empowered team is among the most powerful forces in product. That’s a team that can determine if an opportunity exists; that can pivot if it doesn’t; that can pursue multiple solutions to a prioritized problem set; that can directly marshall the resources necessary for its next move. The importance of the team is why our PUSH ME mantra concludes with E, for Empower a team. 

The problem? The empowered team can seem too ideal and too simplistic. Does an empowered team even exist?

In this article and its accompanying video, Peter Yang from Creator Economy interviews Chris Jones of the Silicon Valley Product Group (SVPG) about this very issue. Jones’s company, SVPG, is led by Marty Cagan, of course. Jones and Cagan literally wrote the book on empowered teams.

Jones offers some phenomenal insights, including reminding product managers that empowered shouldn’t mean freedom to work on whatever you want. He even mentions that teams might be over-empowered.

“Maybe [some teams are] over-empowered…I mean, empowered is a cool word but it it also is a very feel-good word. I think people hear that and they might overhear it as saying, ‘look I'm empowered, I'm on this team, I'm going to work on what I want to work on‘…When in fact that's really not what we mean by empowered. What we mean is that you are actually allocating problems onto teams. Leadership takes an active role in defining what those problems are.”

Chris Jones, SVPG

Here at Pollinator HQ, we find it useful to consider the grammar of the simple phrase empowered team. Empowered is an adjective formed from a verb—in this case, from the verb to empower. We English speakers make adjectives from verbs all the time: thrilled crowd, fried rice, burnt toast, chosen one.

Like most such adjectives, empowered is in the passive voice, meaning the subject of the verb, the one who empowers, is not mentioned explicitly. But that doesn’t mean the subject, the empowerer, doesn’t exist. For a team to be empowered, adjective, someone needs to empower it, verb. That’s a role that senior leaders should own. It’s why in PUSH ME, we frame empower as an imperative verb, not an adjective. This reminds leaders to act: fund the team, motivate the team, enable the team, inspire the team, support the team. In one word: empower the team.

Outside the box

Randomness is a weighty mathematical concept with many practical uses, like conducting drawings, making matches, or selecting from options without bias. Random.org is a venerable website containing tools and content related to randomness. The design is refreshingly spare, and the tools are simple and usable. They’re based on a cool bit of randomness in the universe: atmospheric noise.

Watch: I’ll use random.org’s tools right now to generate a random whole integer between 1 and 100…beep boop beep…38.

Thirty-eight. That has to mean something, doesn’t it? Actually, no it doesn’t. That’s the point.

Check it out at random.org.

About the Pollinator

  • The Pollinator is a free publication from the Product practice at Solution Design Group (SDG). Each issue is a curated digest of noteworthy content and articles from across the internet’s vast product community.

  • Solution Design Group (SDG) is an employee-owned digital product innovation and custom software development consultancy. Our team of over 200 consultants and other technology and business professionals includes experienced software engineers, technical architects, user experience designers, and product and innovation strategists. We serve companies across industries to discover promising business opportunities, build high-quality technology solutions, and improve the effectiveness of digital product teams.

  • The Pollinator's editor is Jason Scherschligt, SDG's Head of Product. Please direct complaints, suggestions, and especially praise to Jason at [email protected].

  • Why The Pollinator? Jason often says that as he works with leaders and teams across companies and industries, he feels like a honeybee in a garden, spending time on one flower, moving to another, collecting experiences and insights, and distributing them like pollen, so an entire garden blooms. How lovely.

Reply

or to participate.