Product folks love the language of science. We talk about experiments and hypotheses, and we use trials and A/B tests to collect results and validate our learning.

I should start by noting that, while I’m not a scientist by training or profession, the terminology and models of the scientific method make sense to me intuitively. They’re a healthy way to describe product thinking applied to product development and business strategy. Saying “Let’s run an experiment” helps me understand that we want to start with something that will teach us something, in order to ultimately discover and deliver value.

I have learned over a long career, though, that some corporate leaders, particularly those responsible for financial performance, might tremble at this entire metaphorical framing. We say “conduct an experiment,” they hear “mess around haphazardly.”

"Hold on, product maverick,” says the CFO making budgeting decisions. “You want to experiment on our business? And you just have a hypothesis that you want to test? This company isn’t a lab for your chemistry project. Come back to me when you have a better plan.”

That’s normal and natural, especially for people whose career and training have focused on earnings and costs. And while we product pros might fight their reaction, such a fight is not really winnable, or even necessary.

So here’s a tip, even a trick: convert your scientific language to financial jargon. After all, finance, just like science and product, involves uncertainty, risk, learning, and, ideally, advancement.

So the next time you are talking to a CFO or other business leader who is making decisions about what to fund in order to build the business, try a new family of terms. Here’s a quick guide to making this shift:

Reserve the science lingo for talks inside the product team or maybe for your next date night. When you’re working with people making investment decisions, speak their language.

On to the Garden,

But first, a word from our sponsor

At SDG, we measure success of the Pollinator by two primary metrics: Open Rate (content value) and Current Subscribers (audience size). Thanks to you, readers, we’re doing pretty well on both metrics, but like any good gardeners, we want to grow.

As we consider how to maintain our high open rate while growing our footprint, we want to hear from you, our readers.

• What do you find valuable about The Pollinator?

• How might it be more useful to your work?

• What one thing would make it a must-read for you?

• What would make you more likely to share it with others?

Please share your thoughts in the comments, or email the editor at [email protected].

Around the Garden

Fear of Commitment

Check it out: The Options Trap: why C-Level Teams can’t Commit by Stephanie Leue, Inside Product

Stephanie Leue is a top-tier product consultant, and she writes like a champ, too. Here she explores why a glut of seductive options actually can crush an effective product practice. A fundamental problem she diagnoses is that having many options on the table feels like visionary-grade flexibility.

She also includes an actionable list for making bold choices. My favorite? “One-Pagers Over Slide Decks: Track the progress of bets on a single page tied to executive compensation. If the bet fails because of waffling, the bonus reflects it.” That hits the waffling decision-makers right in the wallet. Oof.

I see Leue’s article as a thoughtful plea for a kind of inspiring and decisive bravery in the face of overwhelming, alluring optionality. That’s actually a pretty good definition of Leadership.

The seven-day itch

Check it out: How to test a product viability hypothesis in 7 days, by Konstantin

The writer, a product leader and entrepreneur named Konstantin, suggests a systematic method for testing product hypotheses in a compressed period of time. My favorite of his steps is the first one: Clearly formulate the hypothesis. Don’t just loosely conceive what you think might improve or change; write it out, with specificity.

Here’s his whole method, summarized.

• Day 1: Clearly formulate the hypothesis

• Days 2–3: Smoke test instead of development

• Days 4–5: In-depth interviews

• Days 6–7: New hypothesis and quick test

Konstantin then organizes the process into an acronymn called SPRINT. He concludes with some common mistakes he’s seen during the process. I like this one.

But what does it mean?

Check it out: Meaningful Product Experimentation by Shane Murray, Monte Carlo

At bottom, I’m a language man. I love nothing more than a well-turned phrase or a clever bit of wordplay. I think great writing is a hallmark of great products, and I instinctively approach product-making like the creation of a great narrative, perhaps to a fault.

But a good product professional also deeply, profoundly values expertise in data. And that’s the filter through which I read this extensive post in a series by Shane Murray. He’s from a business called Monte Carlo. They offer a SaaS platform that uses data and AI to improve products and businesses.

This piece is written for data product analysts, but anyone involved in product decisions will find value in it. It describes how to construct hypotheses and collect data so that your product experiments generate real insights that you can act on.

More Blossoms

Some of the best stuff we’ve encountered for product pros recently.

• Product topology: Defining products, platforms, and services, by Sam Quayle, Hyperact

• TBM 402: The Real-World Journey to Value and Product-Centricity, by John Cutler, The Beautiful Mess

• The Illusion of Alternatives, by Noa Ganot, on Medium

• The Big Short meets Marcus on AI, by Gary Marcus (with link to YouTube)

Outside the Box

I love when I idly think of something that the world needs and then discover that it exists. The Art Story is such a thing. It’s a comprehensive, data-driven website of artists and art movements through history. You can filter artists by movements, nationalities, and other dimensions, and read well-crafted summaries and biographies while looking at the impressive output of humanity’s craft and creativity. It’s a great site for rabbit-holing and doom-forestalling.

Check it out at The Art Story.

About the Pollinator

• The Pollinator is a free publication from the Product practice at Solution Design Group (SDG). Each issue features an opening reflection and 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.