“Les Jardiniers (the gardeners).” Gustave Caillebotte (1848-1894). Public domain, via Wikimedia commons.

I really like IT pros. They tend to be smart, affable, hard-working people. It’s probably accurate to say that I am an IT pro. I have worked in IT departments and reported to CIOs. My SDG colleagues and I are often hired as consultants by IT leaders. And I’m sure many people reading this essay consider themselves IT professionals, even as they consider themselves product professionals.

IT pros are skilled technologists who understand software, hardware, data, infrastructure, and interface. So there’s a simple and reasonable belief by people in other professions that if something at a company involves computerized tech, it is, by definition, an IT concern. This presumption is especially tempting for companies that started as something other than software companies. These companies naturally think of their products as something manufactured, grown, shipped, printed, or otherwise physically built. The software stuff, running on computers? That’s not product. That’s IT work. Or so this thinking goes.

But this simplification—that IT is the place in an organization where technical skills live—leads to a structural or organizational mistake. Companies might reflexively house anything digital, anything consumed or created through these computational devices that dominate our world, in an IT department. And in the IT department, the work is subject to IT budgeting, governance, project management offices, and similar structures.

And that might not be the best environment for product innovation.

See, fundamentally (yes, this is a gross reduction), IT departments exist to make a business run smoothly through technology. Success for IT is often quiet: we didn’t get hacked, we didn’t crash, the upgrade was painless, therefore we succeeded.

Product, conversely, exists to delight users and win markets. Success for a product team may be noisy. It might be disruptive. So governance and funding structures designed for IT may not be right for product.

AI tools have made it even more important for companies to reconsider IT departments as the presumptive home of digital innovation. These tools have changed the barriers for participating in digital product work. Ideation, prototyping, design, exploration, and even software development are increasingly accessible to people outside the IT department. That doesn’t just change timelines and budgets—it changes org charts. (Yes, I realize that sentence—a statement, an em dash, a contrary proposition—looks like an AI pattern. I tell you, it came straight from my own AI-free pen.) And this change creates new opportunities for product-making. At the very least, it reminds us that product doesn’t need to be governed like IT is governed.

The good news: many companies have developed models that we can learn from. In your next online search or GenAI chat session, ask about the org structure of a digital product you appreciate. I bet you’ll find out that it wasn’t built by an IT department. This isn’t just true for software companies like Google or Duolingo. For example, John Deere, the legendary maker of tractors and similar agricultural equipment, houses an organization called the Intelligent Solutions Group (ISG) where cross-functional teams work on software innovations for the business. At SDG, we have seen many similar examples of product engineering functions working alongside, not within, IT department partners. The best usually involve cross-functional groups of product managers, designers, and makers (the classic Product Triad) working together, across reporting boundaries.

So if you’re a product pro working in an IT department, where approvals are governed through a Project Management Office and resources are funded like an IT project, consider what it would look like for your product-making to operate differently from IT. Even if you love IT—even if you are IT—this might be the most important change your company could make.

On to the Garden,

Around the Garden

Confidence Game

Check it out: LinkedIn post from Stephanie Leue on overconfident product content.

In this LinkedIn post, wise product consultant and Stephanie Leue shares an anecdote about a colleague with years of experience in product management and leadership who has been discouraged by the glut of content from self-proclaimed experts who confidently claim to know what the best product managers do differently, usually involving AI. Here’s an excerpt.

When I read this, I felt grateful to Leue for pointing it out. I too have been exhausted by the trend in product content spaces (LinkedIn, Medium, others) to declare what everyone is doing wrong or what the real secret is and how there’s some inside info that the poster possesses and that everyone else is missing. Leue plainly identifies the cost of this: “And somewhere a capable, thoughtful person reads it and quietly starts doubting themselves.”

The antidote to the anecdote: genuine, human connections with other product professionals who are on the same journey. That’s why I so appreciate this Pollinator community. To the garden I say: don’t let the glut of product and UX (or other tech and business) content written in the mode Leue describes cause skilled and caring professionals like you to question your own competence. A healthy community should in fact be building that competence.

Let it go

Check it out: Vibe Coding in Prod (Responsibly). Talk by Erik Schluntz (Anthropic). Shared by Opinion AI (Substack).

I received an excited text from SDG’s president one recent evening. You have to watch this video, he advised. It’s brief — just fourteen minutes of your time. But product makers and managers will see our roles change in these fourteen minutes.

The speaker, Erik Schluntz, a researcher at Anthropic, addresses technical concerns about leaf nodes and technical debt. But his focus is on how software developers can embrace vibe-coding, or writing software through dialogue with Artificial Intelligence agents. His conclusion? That vibe-coding increasingly enables software-makers to “let go of code”—Schluntz uses the phrase “let go” several times—and to focus on experience, value, and users. In other words, to spend their time in an abstraction layer called product.

Synthetic users is people!

Check it out: How Synthetic Users are changing product decision making (podcast). An interview with Tom Charman (Co-founder at Blok). The Supra Insider podcast.

At SDG, we’ve used AI chat tools to simulate user research. We’ve defined test partners and buyers for our consulting services and then, as those personas, generated insights on proposed refinements and additions to those services. While it’s not a replacement for analysis with people (I love meeting with people), I’ve found that conjuring these “synthetic users” through AI can sharpen a product team’s understanding of its products and its market, at high speed and low cost.

As I was considering the pros and cons of these approaches to research, I encountered this podcast with a thoughtful fellow named Tom Charman. He’s the CEO of Blok (joinblok.co), an AI-powered “synthetic user simulation platform.” Charman has thought long and hard about user research and how AI can improve it. He’s especially articulate about the drawbacks of using common prompt-based LLM platforms, vs. specialized tools with built-in psychographics like his own product.

Even if you never use Blok or similar tools, this podcast will improve your thinking about using AI in user research. And who doesn’t love improved thinking?

(Note: SDG has no relationship with Blok. We just appreciated its founder’s understanding of AI and user research.)

I’m a creep, I’m a weirdo

Check it out: Silicon Valley has forgotten what normal people want, by Elizabeth Lopatto. The Verge.

In this provocative and undeniably witty essay, technology journalist Elizabeth Lopatto reflects on the hubristic tendencies of some technology leaders to believe that they have some special understanding of human history and human psychology, and therefore that they are best equipped to change the future of, well, humankind. She argues that too often, such leaders forget what “normal people” actually want, and therefore products suffer.

Product pros like you and me will appreciate Lopatto’s reminder that our fundamental job is to uncover a user need and respond to that need. That’s helpful no matter what you think about technology trends.

Outside the Box

Solution Design Group’s unofficial mascot is the eagle. We think their ability to soar high and dive deep, their keen sight for opportunities, and their commitment and tenacity are a great representation of our mission and values. Plus our home state, Minnesota, is home to one of the largest populations of bald eagles in the nation. For several years now, Minnesota’s Nongame Wildlife Program has maintained an EagleCam. It’s trained on an aerie along the Mississippi River, which is occupied by a breeding pair. The female of the pair laid her eggs in February. They likely hatched in March, and usually the fresh eaglets make their debut on camera in late April and early May.

Check it out at https://www.dnr.state.mn.us/features/webcams/eaglecam/index.html

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 jason.scherschligt@solutiondesign.com.

• 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.

“The coffee is brought to the carpenter,” Erik Henningsen (1856-1930), Public domain, via Wikimedia Commons.

I’ve been thinking lately about the collision of the old and the new, the late and the soon. Maybe it’s because I just had a birthday, or because in this corner of the world we recently went from a winter-like blizzard to a summer-like swelter in less than a week.

Or maybe it’s because of AI.

A natural response to rapid change is to retreat into the familiar. When pressures of work or the world stretch my limits, I find comfort in objects made with craft and care. Among the items that soothe my soul are a well-seasoned cast-iron pan that’s great for omelets; the Japanese-made guitar my mom bought for my dad in the 1970s; a favorite pair of leather boots; and this morning’s cup of rich, black coffee whose beans I ground myself, served in a custom-made pottery mug, a gift from a friend.

While I revel in the craft behind these objects, I also appreciate the miracles of technology that conjured each of them. I ground those beans and brewed that coffee with electronic gizmos that I paid too much for. The cast-iron pan was undoubtedly designed with clever CAD systems and state-of-the-art manufacturing methods. I’m sure that the bootmaker’s top-tier digital marketing makes my boots popular and possible.

“Respect for the craft, wonder at the possible, caution for the risks” is how we software product pros might incorporate technology and methods made possible by Artificial Intelligence. We can and should love our product craft: the research, the users, the writing, the collaborating. But that shouldn’t prevent us from adopting new capabilities to accelerate that work, improve our output, offer more value. And at the same time, the promise of new capabilities shouldn’t mask their risks, either.

None of this is in conflict. All are possible at once.

With the advent of AI-enabled tools and methods, the garden we product professionals dwell in has gotten undeniably richer—but also more treacherous. (And yes, that sentence’s em dash is all mine, and isn’t it weird and a little sad that I think I need to say so?). There’s new fruit to harvest, and it’s delicious, and new pests to eradicate, and they’re stubborn. Sometimes, the best tool for the job is the old shovel we’ve carried and maintained for decades. Sometimes it’s not.

Pull on your favorite boots and finish off that cup of artisanal coffee. There are new things to learn. And the new ways need your old skills.

On to the Garden,

Around the Garden

A conversation with the self

Check it out: I’ll Know It When I Build It, by Christina Wodtke, the Elegant Hack

Consultant and entrepreneur Christina Wodtke explores something I hadn’t considered: product-making with AI is closer to the act of drawing than to traditional software engineering.

Her argument: before AI, software-making required you to carefully plot out the work ahead of you, and then to execute the thing you planned. But AI’s ability to respond incrementally means you can work like an artist works on a drawing: starting with rough forms, seeing what works, erasing lines, discarding, restarting, adding new, building up, all while witnessing the thing you are making evolve in response.

She describes the act of drawing as a conversation with the self and a thinking process made visible. The same can be said for other creative efforts. For example, I often have profoundly enjoyable experiences when working alone on creative writing projects. I dump, draft, delete, refactor, rethink, trim, tighten. Heck, I’m doing it while writing this Pollinator! Writing in conversation with myself is a deeply satisfying way to work, and it results in the best final output.

Wodtke’s idea is that AI makes that kind of rhythm available for software product development, at least up to the level of the prototype. To be clear: she’s not saying AI is great for the making of art (that’s a separate discussion); she’s saying AI can apply deeply human, non-AI art-making processes to the making of software.

I think Wodtke has hit on something here.

The unreplicateable

Check it out: The Human Touch in Product Management: What AI Can’t Replace, by Eddie Pratt, Product Focus

Eddie Pratt from Product Focus writes like a product manager thinks. He implicitly gets that the heart of the job is applying judgment and decision making to build a value-generating system. Like many in the profession, he’s wrestling with how to apply AI capabilities while retaining human judgment and the value of personal encounters with users and teammates. I like his framing in this article of “what AI can’t replace.”

He starts the piece by describing an AI-assisted customer research effort that resulted in an outcome that surprised him: the value of the human sources.

His description of “something that AI could never replicate” is inspiring.

Here’s his list of what AI can’t replace:

• Deep Customer Understanding.

• Cross-functional Collaboration.

• Adaptive Learning.

It’s probably incomplete, and it may be unique to Pratt’s own context, but it’s a great start.

Optimism from O’Reilly

Check it out: How we bet against the bitter lesson: skills and the knowledge economy, by Tim O’Reilly

Tim O’Reilly of O’Reilly Media is a legendary spreader of technology information and insights. Here O’Reilly confronts something called the “bitter lesson” from Rich Sutton: the idea that, over time, methods powered by sheer computational force tend to outperform approaches shaped by human knowledge.

O’Reilly asks if new methods and tools like Agent Skills (a standard for intelligent agents to use instructions to do things more accurately) mean we can bet against this bitter lesson. He isn’t definitive in his answer, but he offers the possibility that we can, if we recognize AI as a social and cultural technology, more akin to language than to machine.

Why does this matter for product managers and teams? We’re bombarded with pleas to work faster, learn new tools, race against and with our replacements. We might be about to learn the bitter lesson: the robots will win out. But there’s a parallel story where learning from each other and extending our value in a knowledge economy (through domain knowledge, judgment, taste) offers advantages that pure scaling can’t yet match. The yet there is critical. Perhaps our challenge is to extend the yet.

How Delightful

Check it out: The Power of Product Delight in Tech Products, from Nesrine Changuel (YouTube video)

I recently attended a webinar that featured French product leader Nesrine Changuel on the topic of Product Delight. Changuel developed her theory of delight in product over a long career working on products at Spotify, Google, and Microsoft—and picking up a Ph.D. along the way.

Her approach is rigorous and systematic. Product managers can inject delight in their products by segmenting users by motivators, which are a combination of functional and emotional drivers.

Some other lessons from her talk:

• Delight is not aesthetics, and it is not gamification.

• Delight is a business driver. For example, delighted customers are 50% more likely to stay.

• The classic double-diamond model can be reframed to start with Motivators.

• A good portfolio mix looks like this:

  • 50% low delight features (functional drivers only)

  • 40% deep delight features (functional + emotional drivers)

  • 10% surface delight features (emotional drivers only)

To get started, use her motivator grid, available via Changuel’s newsletter.

I found her talk, well, delightful. Thanks to Nesrine Changuel for her work, and to ProdPad for hosting the webinar.

Outside the Box

Pollinator HQ is housed within the offices of Solution Design Group, a custom software development consultancy based in Minneapolis, Minnesota, USA. This website, the Minnesota Natural Resource Atlas, might primarily be interesting to fellow Minnesotans, but man it is fun. It’s from some wizzes at the The Natural Resources Research Institute at the University of Minnesota. The website offers cool data geographic visualizations of lakes, rivers, forests, and similar resources. It’s mostly for academic purposes, but the rivers & streams map alone, veined red and blue with waterways, will set a river-lover’s heart a-flutter.

Check it out at https://mnatlas.org/.

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 jason.scherschligt@solutiondesign.com.

• 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.

David Teniers the Younger (1610–1690) (after), “A Chemist in his Laboratory.” Victoria and Albert Museum. Public domain, via Wikimedia Commons

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 jason.scherschligt@solutiondesign.com.

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 jason.scherschligt@solutiondesign.com.

• 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.

John James Audubon (1785-1851), “Great Northern Diver or Loon,” Public Domain, via Wikimedia Commons.

Pollinator Community,

Longtime readers know that here in the Garden, we approach product work as broader than simply prioritizing features and driving to delivery. Rather, we treat it as a job of making meaning, solving problems, and building communities through the services, technology, and experiences that organizations deliver to their customers. In other words, Product and UX is human work. You may have even heard me describe a product as a vehicle for an organization to put its mission into the world.

The Pollinator and Solution Design Group (SDG) are based in an inner-ring suburb of Minneapolis, MN. Because of harrowing recent events here in our beloved Minnesota home, and in keeping with SDG's company values of Serving Selflessly and Thriving Together, SDG's Pollinator Editorial Committee has decided not to publish the typical Pollinator that we had originally prepared to send this week. The breezy 1980s New Wave reference we had designed our opening essay around can wait.

As we pause, we invite you, our garden of product practitioners, to make meaning, solve problems, and build communities. To do human work.

To that end, we've curated a selection of resources on product for meaning-makers and community-builders.

Next month, we'll return to our regularly scheduled pollinating.

On to an abbreviated Garden,

Product Resources for Meaning-Makers and Community-Builders

A curated list for the Pollinator community.

• Product communities of practice: everything you need to know, by Petra Wille

• Mission-driven product management, by Kyle Grant, in Extra Credit: A Tech Blog by Guild

• Lessons learned from six years of building a community of practice, by Scott Colfer

• Building communities that work, with Emily Webber on The Product Experience, from Mind the Product

• Finding your purpose in product management, by E.R. Burgess, on Medium

• Why communities help you build better products, by Scott Baldwin, Productboard

• Finding fulfillment, by Jason Cohen, A Smart Bear

• Building mission-driven products in regulated industries: lessons from 20 years in product management, hosts Amanda Vandiver and Adam Landis, with guest Patrick Wesonga, How I Grew This (podcast)

• How to launch and market your online community, by Carrie Melissa Jones (YouTube video)

• Empathy: how the best product managers achieve customer-centricity, Petersen Product Strategy

• One thing that has sustained me (on the power of community), by Jason Knight, on LinkedIn

Note on this issue’s title and heading image

L'Étoile du Nord is the official Minnesota state motto. It is French for “The Star of the North.” North Stars are also important to product teams.

The John James Audubon painting is the Minnesota state bird, the Common Loon. Loons are an iconic motif in SDG’s home state.

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 based in Minneapolis, Minnesota, USA. 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 jason.scherschligt@solutiondesign.com.

• 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.

Double portrait d'une fillette (Double Portrait of a Young Girl), Paul Gauguin, Public domain, via Wikimedia Commons

IT vs. The Business. Projects vs. Products. Discovery vs. Delivery. Agile vs. Waterfall. Outcomes vs. Outputs.

If you work in product, you’re probably familiar with these pairs. Digital product or agile development coaches often apply binary, oppositional frameworks and mantras. These A vs. B slogans suggest that a great way to navigate complex transitions in organizational processes is to just slice the subject in two. For example we might ask, What’s product management? And an easy answer is, It’s not project management. Using this approach, we divide a problem and compare the quivering halves. Perhaps a product team’s toolbox should include a cleaver, right next to the Eisenhower Matrix and North Star Framework.

Certainly, these binary models can be useful, especially for teams just getting comfortable with product concepts and methods. I use them too. In fact, I’ve applied product vs. project, outcomes vs. outputs, and discovery vs. delivery already today, and it’s only noon.

But defaulting to binary divisions also can be dangerous. Why? Because it simplifies and reduces things that are complex and expansive. That can lead to poor decision-making, leading in turn to suboptimal outcomes.

And yet our product profession is surrounded by these dualities. For example, a web analytics company recently conducted a survey of product managers by asking another binary question: Is product management an art or a science?

While I suppose I agree with their conclusion—that it’s both—and there’s some excellent insights in the responses they received, and I bear no ill will to that analytics company, I still wonder: why are they even asking this question? Framing product management as art vs. science manages to simultaneously misunderstand three domains: product management, art, and science. It’s a binary construct that reduces a complex, multi-faceted domain into a simple choice between two options, like soup or salad, country or rock and roll, paper or plastic. And that reduction can limit how a product manager thinks and works.

The alternative is to think along spectrums or continuums. Where binary thinking requires choosing between two options, spectrum thinking considers alternatives like both, between, other, and neither. Here’s a simple visualization of this from a writer named Emma Reed, in an essay called Binary Thinking: The Polarization of Mind and Reality.

So yes, use matched pairs if you must, and if you’re feeling frisky, go ahead and insert that confrontational “versus” between them. But don’t let those two options prevent you from considering spectrums, gradients, dimensions, or alternatives. The next time you’re facing a binary choice, recognize that your solution might require blends, or perhaps be on a different path altogether.

Good product professionals don’t just flip switches; they turn dials. A paradox of our field is that to build a great digital product, it helps to work in analog.

On to the Garden,

Around the Garden

Silent killer, qu'est-ce que c'est

Check it out: Binary bias: the silent product sense killer, by Naomi Anezu

In this brief, thoughtful essay, Product Manager Naomi Anezu boldly names the tendency to break experiences into two extremes a bias, and she connects this bias directly to failures in product management. Especially useful: her recognition that a binary bias can cause product managers to neglect the needs of our users.

Anezu then identifies tactics product managers can use to overcome this bias, like “Seek Collaboration” and “Test and Iterate.” It’s hard to argue with any of her analysis or advice. But I’m biased.

Two crafts, one purpose: product & design

Check it out: The value of design in a product organisation, by Dan Ramsden, in Bootcamp, from UX Collective

One of our talented SDG UX strategy consultants and I chatted last week about a course he’d recently taken on product mindsets. This colleague remarked that a lot of the course’s content was so similar to things he’d learned through his extensive design training and career. I couldn’t help but concur. We agreed that design work—his domain—and product thinking—my domain—are in fact profoundly similar, especially as you get more advanced in your practice and the types of problems you work on.

Later that very week I came across this article from design strategist Dan Ramsden, a creative director at the BBC. Ramsden addresses many of the overlaps and conflicts that my colleague and I had just discussed.

Ramsden then describes a continuum of approaches that includes space for product managers and product designers (and other members of an effective product team) to work together. Here’s how he visualizes this:

From Dan Ramsden’s description of Deduction, Induction, and Abduction on product teams, in The value of Design in a product organisation

I hoped the article would conclude with some actionable steps designers can take to reinforce their value to product teams. But perhaps that wish is what Ramsden is cautioning against. After all, a list like that would be reductive and binary. Ramsden is thinking in spectrums.

Check your head

Check it out: Product Operating Model Health check, from Hyperact

The boutique British product development firm Hyperact continues to produce a wealth of world-class advice and tools for product practitioners. Their latest treasure: this simple but useful assessment for any organization wanting to analyze the health of its product practices. We’ve run the assessment through its paces, and we think the level of depth is exactly right for product or strategy leaders.

The assessment is organized into four dimensions: Leadership, People, Process, and Impact. After users complete a quick 10-minute survey, the tool concludes with a nice report, including data visualizations. You’ll need to supply some personal info to receive your results. But Hyperact’s content is worth it.

By the way, SDG has its own tools for assessing the health or effectiveness of a product practice. If you’re interested in learning more, let’s talk.

More Blossoms

Here’s some good reading on binary thinking for product leaders.

• How to Avoid Binary Thinking and Think More Clearly, by Clay Drinko, Lifehack

• Why Full Spectrum Thinking is better than Binary Thinking, by Ditya Mahandaru

• Challenge Binary Thinking for Better Results, by Amy Drader, Growth Partners Consulting

• Stop Choosing Sides: Why the Best Solutions Come from False Choice Rebellion and Critical Thinking, by Richard French

Outside the Box

A few weeks ago, the world’s greatest spreadsheet athletes gathered in Las Vegas for something called the Microsoft Excel World Championship. In this annual event, competitors are given tables of data and use Excel functions to complete challenges with speed and accuracy. There’s even a championship belt and dramatic pro wrestling-style intros.

Check it out at MEWC - Microsoft Excel World Championship.

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 jason.scherschligt@solutiondesign.com.

• 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.

Miranda - The Tempest, by John William Waterhouse. 1916. Public domain, via Wikimedia Commons. Source: https://johnwilliamwaterhouse.home.blog/2019/05/31/miranda-the-tempest/

One way to think about effective product work—or, I suppose, about anything involving human priorities and decisions—is as a system of systems. These systems operate at different depths or altitudes. They each apply forces to people and products—and to other systems. Ideally, the systems are working in concert to produce outcomes that are meaningful for your market and your business.

I think we product pros understand the system comprising the daily work of cross-functional product team members, like designers and developers. They’re researching a problem or identifying new priorities or coding a solution to resolve a Jira ticket. This system works to produce an increment of value. And this system, this team, is where many agile coaches and project-to-product transformers spend their time. Like a crew guiding a ship across the surface of the sea, the functional product team is usually eager to operate with trust and agility. If we remove barriers and improve intra-team processes, we can help them do so.

The problem? Many well-meaning product transformations don’t actually address the systems that have the biggest effects on the product’s success.

For example, one of the most influential systems on your product model is your organization’s corporate budgeting and planning process. This is the system through which executives and department heads allocate resources for an upcoming fiscal year. Senior leaders are basing these allocations on estimates of costs and predictions of value. If you don’t know what they committed to doing and delivering in this system—say, a promised feature or a fixed release date—every adjustment you make to operating like a product team is unlikely to succeed. This is why so many organizations that adopt product models still struggle: the system that disburses money, people, and attention hasn’t changed.

In an ideal system of systems, the forces generated by each subsystem contribute to other subsystems with maximum efficiency and positive effects. The big wheel turns the little wheel; the little wheel drives the piston; the piston spins a camshaft; axles turn; gates open; rewards are dispensed. Of course, in our universe featuring flaws, failings, and a fair amount of chaos, perfect systems are probably impossible—but we can still strive to optimize what we’ve got.

If your business is allocating resources to projects with anticipated outcomes, you’re working against a powerful undertow. Even if your cross-functional team is rowing with maximum alignment, you can still get dashed against the rocks. Your helmsman may be wise and your team may be coordinated, but you’re steering against a tempest.

So don’t just row your boat; inspect the wind and the sea. That may be where your transformation needs to focus.

On to the Garden,

Around the Garden

Funding is where it starts

Check it out: How to transition from funding projects to funding products (Lucid blog)

In this post, the bloggers at Lucid Software tackle product funding head-on. They start by recognizing that time-bound, estimate-based, feature-driven project funding processes often result in “Wasted time. Wasted money. Hampered agility. And unsatisfied customers.”

And the post doesn’t simplify the solution (“Instead, fund products. Next question?”). Instead, it offers details on how to fund products: by allocating consistent, predictable resources that technology teams can use to generate value, with flexibility about what exactly they discover and deliver. I wish the bloggers didn’t refer to an “IT team,” but that’s a small complaint.

The best part? The bloggers recognize that this model requires funders (executives, etc.) to adopt agile mindsets, which in turn means trusting managers and teams to make good decisions, iteratively. At the same time, those product teams are on the hook to communicate thoroughly and transparently about the outcomes they’re producing.

Why not both?

Check it out: the false narrative of shifting from project to product—and why you need both, by Laura Barnard, for CIO.com

A project-to-product transformation, by definition, rejects project processes in favor of product management models. But in this wise article for CIO.com, strategist and transformation expert Laura Barnard argues that the skills and models of product management and project management should both apply to many corporate technology initiatives. In a nutshell: companies need product thinking, yes—but they also need project management skills. Smart orgs figure out when and how to apply both models.

We’re fans of anyone who upends lazy binary thinking, like Barnard does here. Every one of us is a little bit country and a little bit rock-and-roll. We’ve often described the difference between projects and products like this: manage projects to end; manage products to endure. Often, executing a project that ends is necessary to operate a product that lasts.

Leading like a boss (when you’re not a boss)

Check it out: Product Leadership FAQs and Leading Without Being the Boss: Tips for Product People, by Roman Pichler

One of the enduring challenges of a product manager’s job is to lead and influence without direct org-chart-level authority over other members of the product team. You’re directing people’s work and priorities, and you don’t actually oversee their job performance and career paths. That dynamic can be tough for even the most self-aware and intelligent person to navigate. It’s why charm is one of a product manager’s most critical traits.

In these articles, top-tier product guru Roman Pichler offers clear, actionable guidelines for leading as a product manager, even when you aren’t the direct supervisor of the people you are leading.

The skills he advises you develop and demonstrate are:

• Build Trust

• Show Empathy

• Communicate Effectively

• Set Clear Goals

• Practice Collaborative Decision-Making

• Address Conflicts

• Practice Self-Leadership

Pichler also explains that trust and influence are essential to this kind of “emergent” leadership. His articles feature excellent diagrams that clarify how to lead by guiding and aligning, even if you lack positional authority.

Leading through guidance and alignment, from Roman Pichler. (Yes, we noticed his missing “n” in “Aligment.”) Source: https://www.romanpichler.com/blog/leading-without-being-the-boss-tips-for-product-people/

Hooked on the Classics: Cagan from ‘08

Check it out: Moving from an IT to a Product Organization, by Marty Cagan (2008)

This is the first article of Marty Cagan’s that I ever remember reading. It’s seventeen years old now, but back then, when my children were small and my beard was dark, this brief, rich post got me thinking big thoughts about the great place where I then worked (an online university) and what we needed to do to build our digital products effectively.

We still appreciate Cagan’s advice to “First draw a clear line between customer-facing software and internal software. The demands are different, the skills needed are different, and you will find you need different staff, processes and resources.” That’s one of the most radical and valuable bits of advice that an organization can adopt. And we’ll repeat: there’s nothing wrong with IT departments. I love IT departments. But they often measure success by crashes averted, hacks dodged, and projects completed, not by customers delighted and businesses built.

Cagan concludes with this enduring wisdom:

If you’ve never read this article, give it a whirl. If you have read it, well, read it again.

Outside the Box

Optical illusions and similar brain-bending visual puzzles appeal to almost anyone. If you’re in the mood to blow your own mind, point your browser at Optical Toys. It’s a collection of animations and images that use brain science to mess with your perception. Each includes a nice explanation of how the effect works. I recommend only spending a few minutes at a time on the site—any longer, and your sanity might be threatened.

Check it out at optical.toys.

The horizontal lines in this image are straight, parallel lines. The only explanation? Your mind must be a witch. Image source: https://optical.toys/cafe-wall/

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 jason.scherschligt@solutiondesign.com.

• 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.

Percival Arrives at Grail Castle. From a 1330 manuscript of “Perceval ou Le Conte du Graal” by Chrétien de Troyes. Artist unknown. Public domain. Wikimedia commons.

Earlier this month I presented on SDG’s behalf at Product Camp Twin Cities, a local conference sponsored by the Twin Cities (Minnesota) chapter of PDMA. My topic was how product managers can use the mindsets and tools of editors (in journalism, film, and books) to deliver stronger products.

An idea I explored briefly was that product management is a narrative discipline, as much as it as a technical or business discipline. Indeed, we already use narrative language in our tech product jargon: consider terms like user stories, storyboarding, and customer journey maps. So savvy product managers and strategists will read their products as they would a story to a child. And even savvier ones will write them.

A model you might use when reading or shaping your product’s narrative is the hero’s journey, or the monomyth. It’s a common shape of stories, from the Homeric epics to the Wizard of Oz to Lord of the Rings. In it, a hero starts in an ordinary world; they’re called to adventure; they may meet a mentor or companions; they are faced with tests; they overcome them; they are rewarded; and they return to their world, transformed.

This hero’s journey resonates with people across cultures and times. It was identified by the well-known mythologist Joseph Campbell, in The Hero with a Thousand Faces (1949). Here’s a diagram of it from a website called StoryFlint. (There are countless variants of this diagram.)

From “The Hero's Journey and Why it Matters: The Mapping of the Human Soul,” by Kevin Barett, StoryFlint.

I know what you’re asking: “Cool model, bro, but why is this in a product management publication?”

Well, if you work on digital products, you can use your understanding of this archetypical shape to make your products more successful. Just position your user in the role of the hero, and then shape their experience through your product to lead them to reward and return. Let’s call it your Usermyth.

Here’s how elements of this Usermyth might map to product and UX work.

People have been organizing their thinking and experiences in stories since the cave folk gathered around campfires. We can use this truth in our product work. So don’t just plan, manage, design, code, and deliver your product. Write your product. Your users will thank you. After all, who doesn’t like being the hero?

On to the Garden,

Around the Garden

Patton’s story mapping, explained

Check it out: What’s agile story mapping? Key principles and benefits, by the Tempo Team, and The Ultimate Guide to Agile User Story Mapping, by Marjan Venema, Nimble

Product managers and customer experience designers are likely familiar with the technique of story mapping. Basically, on a large physical surface like a big whiteboard or even a wall, a product team visually lays out a product’s stories. Each element is expressed on a small card or Post-It Note. The major stages of a user’s journey progress horizontally; the vertical axis probes deeper into the individual tasks that make up that stage. Once you’ve mapped the stories, you can then demarcate slices that you want to prioritize for development. I love when a boundary gets drawn around a segment of a story map and converted into a priority. It feels like narrative has been codified.

These summaries, from Tempo and Nimble, two project management SaaS tools, explain the technique well. The Tempo post gets into a bit more depth; the Nimble article includes some helpful photographs of story maps.

Also, no one should write about story mapping without crediting Jeff Patton, the agile development guru whose User Story Mapping book (O’Reilly) popularized the technique. He’s one of the Pollinator’s favorite practitioners of and writers about good product work.

An animator becomes a product manager

Check it out: The Art of Product Storytelling: A Product Manager’s Perspective, by Ryan Flynn

Here a product manager named Ryan Flynn describes how his background and training in animation has shaped his experience as a product manager. He points out that “Animation, at its core, is about breathing life into stories visually. It taught me to see beyond the surface, to unearth the narrative heartbeat of every project.”

That image of an “unearthed” narrative heartbeat is a powerful description of a product manager’s duty. I only wish Flynn had said of every “product,” not project.

Remember what a roadmap is for

Check it out: Your roadmap is a prototype for your strategy, by Janna Bastow, ProdPad

This article from Janna Bastow of ProdPad argues that many product managers are misusing their roadmaps by treating them as promises of features by a date. Her recommended alternative? Consider a roadmap a prototype for your product strategy.

She makes a compelling argument. I’d put it this way: a company’s or team’s product roadmap is the team’s current hypothesis for how they will generate value by solving user problems over time. As a prototype, it’s not actually the fully functional manifestation of that hypothesis. But it is something you can test, and from which you can learn, and which you can use to guide the actual delivery of the product.

I’ve been thinking about this a lot, and I have to say: I like it.

Der Komissar and AI

Check it out: How to survive the weight of an entire industry trying to convince you that you're inadequate, by Mike Monteiro

Designer and writer Mike Monteiro considers Artificial Intelligence and Product Design by tackling an interesting question: “How do I make art without feeling stupid and/or inadequate?” Monteiro’s response inverts the question altogether. To Monteiro, feeling “stupid and inadequate” is the point of creative work. In fact, it’s our most potent way to generate authentic, human work. He then riffs on Falco’s 1980s new wave hit “Der Kommisar” and uses that to explore how creative work is at its best when there’s some stupidity in it.

My favorite part of the essay is when Monteiro confronts buttons in a cloud-based word processor that offer to help the user write, using AI. As Monteiro describes it, “I’m hit in the face by this giant ass-button telling me that I’m probably not good enough to do what I’m trying to do.” This, he counsels us, is the challenge of writing (or other creative and communicative acts) in an AI-driven landscape.

I know it’s not exactly a product and UX article of the sort you expect from the Pollinator, but it’s a pretty compelling exploration of the challenges to creating anything—including a great product. Plus it’s a delightful read.

Outside the Box

Have you run into an interesting technical situation and thought, “Someone probably has built some software that can help here. I just need to find it”? I know I sure have. That’s where Tool Finder can help. It’s a source for scads of online tools and utilities that help with productivity, organization, workflows, calculations, writing, and myriad other tasks. There’s a newsletter, too.

Check it out at toolfinder.co.

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 jason.scherschligt@solutiondesign.com.

• 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.

Prudence and Manly Virtue, Paolo Veronese. c. 1561. Source: WikiArt. Public Domain. https://www.wikiart.org/en/paolo-veronese/prudence-and-manly-virtue-1561

Product work is thinking work. We ponder priorities, outcomes, markets, teams. We weigh usability, viability, feasibility. We question; we consider; we muse. And when your brain starts to steam from all that action, here’s another idea for your product thinking menu: virtue.

Virtue? Isn’t that a concept from Philosophy 101? Exactly. Call it a theory of goodness, a moral framework, even just a way of working toward the good. Without it, we can’t build products that truly improve how people live, act, and treat each other.

Now you’re probably asking, “Is working toward the good really the job of a product professional?” To which I say: “you’re darn right it is.” This doesn’t mean that we should only commit ourselves to products that rescue puppies or dole out hugs. But we can use the virtue of wisdom to make an accountant’s workflow easier; we can use the virtue of compassion to help a patient find the best source for her medications; we can use the virtue of courage to enable a journalist to tell a story from a conflict zone.

To start, check out historical frameworks for how people should best operate in a complicated society. How about Plato? Here is what Socrates enumerates as the four cardinal virtues, in Plato’s Republic (feat. Socrates): Wisdom, Courage, Justice, and Moderation. These eventually became the virtues of the Stoics, too. I think we can trace these straight to a product manager’s responsibilities.

Those Socratic virtues are just one system; there are of dozens of others, originating from wisdom traditions across geography and time. These include Saint Thomas Aquinas’s notion of a good operative habit; Buddhism’s Four Immeasurable states of mind, or Ben Franklin’s Thirteen Virtues. A fellow named Scott Jeffrey has created a helpful, easy-to-read digest of virtue frameworks in List of Virtues: A Master List from Ancient Traditions.

This month’s Pollinator features thinking from other product design and dev pros on these lofty and ancient ideas of virtue and ethics. Perhaps it can help our community get more comfortable thinking and talking about this stuff. After all, technical product work has moral weight. A product is how a company or other organization puts their mission and values into the world and serves the people they want to serve. Done right, that can inspire a virtuous upward spiral of sensing and responding, with value as its vortex. So rescue a puppy. Give someone a hug. Do it through your product.

On to the Garden,

Around the Garden

Design Ethics

Check it out: Ethical Considerations in UX Design, by the team at Design Lab

Design Lab is a product design and user experience initiative that helps train new product designers to enter the discipline. Design Lab maintains this excellent guide on ethical factors that designers should consider in their work on products. It’s more surface-level overview than in-depth analysis, but it’s a great introduction to the topic. It includes brief explanations, examples, and key takeaways to help designers make ethical decisions. Here’s an excerpt.

We also love that the Design Lab guidelines recommend Microsoft’s phenomenal inclusive design toolkit.

Note: Tip o’ the hat to SDG User Experience design consultant Allison Lorenzo for recommending this. And no, I’m not sure that a beekeeper’s hat is actually tippable.

Coders are virtuous, too

Check it out: Seven code virtues explained, by Tim Ottinger, Industrial Logic

Here long-time software developer Tim Ottinger outlines seven virtues for code. His list is rooted in his deep experience as a developer, not ancient wisdom traditions. (Socrates or Confucious are nowhere to be found.) But he does acknowledge that the number seven aligns nicely with classic virtue frameworks. Product managers and developers will find Ottinger’s explanations comprehensive and accessible. Here are his seven code virtues:

Thou shalt share the Pollinator far and wide

Check it out: Eight Commandments for AI: A Consumer's Perspective, by Mickey Muldoon, The Other Mickey Wiki.

I appreciate writers on contemporary issues in technology who approach A.I. with nuance and sensitivity, instead of just saying “this tech is magical!” or, conversely, “this tech will destroy us all!”

Here a product practitioner named Mickey Muldoon lays out eight “commandments” for A.I. technology. His thesis: we need to be thoughtful about how we incorporate Artificial Intelligence in our products and our daily lives, lest we degrade human experience. He also seems to dig bicycles, and in my experience, people who dig bicycles tend to be bright and interesting.

Anyway, my favorites of Muldoon’s list are:

• Thou Shalt Not Allow AI To Make Thee Dumber. (His first commandment.)
• Thou Shalt Protect the Future from the Generative Content Downward Spiral. (His third commandment.)
• Thou Shalt Not Allow AI to Write on Thy Behalf. (His seventh commandment.)

We had a nice little discussion on SDG’s Slack about that “writing on thy behalf” commandment. Personally, I’m something of an A.I.-writing-skeptic. My rationale: the purpose of writing is to work out what you think about something, and A.I. skips that whole step. But my wise colleagues argue, convincingly, that commodity-grade “text generation” can be performed well by A.I. tools. Maybe the answer is transparency: make it clear to readers whether the text was written by a person or by A.I. I hope we all agree that we shouldn’t pretend a poem or opinion essay or bee-themed product newsletter was human-written, if it wasn’t.

Note: Tip o’ the beekeeper’s hat to SDG Artificial Intelligence and Machine Learning consultant Cameron Lis Marcott for his insights.

Consider the dark side

Check it out: 8 Examples of ethical issues in software development, by George Lawton, on techtarget.com

In this essay, London-based technology journalist George Lawton inspects notions of virtue and ethics in software products from the opposite direction: by considering pitfalls or anti-patterns to avoid.

He enumerates eight categories of ethical issues.

• Addictive design.

• Corporate ownership of personal data.

• Algorithmic bias.

• Weak cybersecurity and personally identifiable information (PII) protection.

• Overemphasis on features.

• Lack of transparency.

• Environmental impact.

• Human rights impact.

At SDG, we occasionally lead our customers through “painstorming” exercises to imagine what might go wrong with a custom software development initiative. Lawton’s list is a great way to structure such an exercise.

More blossoms

Product Managers are about to get their jobs back, by Alicia Drinkwater, in Bootcamp

Here product manager Alicia Drinkwater offers hopeful news for Product Managers whose roles have been overtaken by Artificial Intelligence tools. She has a wonderfully optimistic perspective: since A.I. can handle the “feature factory” tasks of product management, now product managers can worry about empathy, value, human impact, and integrated systems—which is what attracted many of us to the discipline in the first place. Bookmark this one.

Applying Virtue Design to Build a High-Performing Product Design Team, by T.J. Nelson

Product manager and designer T.J. Nelson tackles virtue head on. The gist of his argument is that avoiding virtue in product design principles is a “massive oversight.” He then describes how he has used classical virtues in his product design projects, with many great examples from his professional portfolio.

Design Principles in Leadership: Postel’s Law, by Andy Chan, in The Human Business

Andy Chan provides a nice introduction to the Robustness Principle, also known as Postel’s law. It’s one of my favorites of the many “laws” that we run into in business and technology. (The eponymous Jon Postel was a pioneer in developing internet and networking protocols, by the way.) It states that to build an effective (or “robust”) and interoperable system, you should be “conservative in what you send, and liberal in what you accept.” That seems like a good and virtuous guideline for lots of things beyond software, too.

Outside the Box

The Internet Encyclopedia of Philosophy is an incredibly comprehensive but also accessible resource on everything associated with the noble discipline of academic philosophy. I found it pretty useful for preparing this issue of the Pollinator. It’s an initiative housed at the Philosophy department at the University of Tennessee-Martin.

Check it out at https://iep.utm.edu.

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 jason.scherschligt@solutiondesign.com.

• 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.

The Wounded Man (L’homme Blessé). Gustave Courbet. From the collection of Musée d'Orsay. Public domain, via Wikimedia Commons

This summer I’ve been dealing with a frustrating and limiting injury. While performing an ordinary yard work task—hoisting a heavy beam while cleaning up a pile of old lumber—I felt a painful pop-pop in my elbow. An MRI revealed a “full-width rupture of the right biceps tendon.” In late July, I had surgery to repair it. Over the past few weeks, I've been navigating a brace, painkillers, and physical therapy to get back in action. I’m getting better every day, and thanks for asking.

I’m not sharing this for sympathy, but instead to express gratitude for what I’ve been learning through the experience. I tend to find little product and business lessons embedded in too many things. The best of these usually feature good people and interesting systems. And this little orthopedic issue has made me even more aware of the wonder of technology and the glory of teammates.

First, the technology. I’ve maintained my productivity throughout this period due to technology that didn’t even exist when I started my product career. Remote conferencing tools have become boringly, impressively effective; collaboration platforms like Slack keep me ambiently aware of people and work even while I’m lying on a couch; and SaaS platforms make it possible for me to access data, designs, content, and systems from anywhere. I’ve also become fairly adept at using speech recognition software, reducing my reliance on typing, though causing some hilarity when voice access tools pick up surrounding conversation and drop it in a document. And that’s not even considering the marvelous medical technology that made the healing possible at all.

But even more than the tools and the tech, this issue with my elbow has made me grateful for great teammates. A bum wing doesn’t mean bum productivity, if you are lucky enough to work with the kind of people I work with. Leaders at Solution Design Group have given me nothing but support; SDG colleagues have helped fill a few gaps even while I’ve been racing back to health; and my consulting customers have been overwhelmingly accommodating and flexible. It all makes a fella grateful.

Speaking of grateful, this month we thank a team at Blue Cross and Blue Shield of Minnesota for their time and wisdom. They’ve been redesigning their business and technology operating model to focus on discovering and delivering great value-producing products. We were lucky enough to interview them for this issue.

On to the Garden,

Around the Garden

Ruthlessly prioritizing for valuable results: Blue Cross and Blue Shield of Minnesota (BCBSMN) and their product journey

Blue Cross and Blue Shield of Minnesota (BCBSMN) is the largest non-profit health plan in Minnesota. In recent years, the company has shifted from running enterprise projects to organizing around digital and service products, managed by product teams. At SDG, we’ve been impressed with the foresight and persistence behind this change, and we were thrilled when the BCBSMN leaders agreed to share their story with our Pollinator community. It’s an inspiring example of iterative, customer-centered, results-driven product work.

Thanks to these BCBSMN employees for sharing their story:

• Chris Diller, Director of Product Transformation

• Dan Bliss, Principal Product Consultant

• Tiffany Lauria, VP of Execution and Value Delivery

The Pollinator: What prompted BCBSMN to begin a transition to a product operating model? Was there a specific motivator or set of challenges?

BCBSMN: Increased customer demand for affordability, rising operating costs, and intensifying market competition were key drivers. We also recognized the need to overcome internal organizational silos, improve cross-functional collaboration, and become more adaptable to changing environments and emerging technologies.

The Pollinator: Describe the differences between how your teams operated under the old model vs. your new product-driven approach. Are there shifts in mindset, structure, or day-to-day work that stand out?

BCBSMN: Under the old model, accountability wasn’t clear and we couldn’t point to outcomes of our work. We also tended to overcommit, often tapping the same ten people for critical initiatives. With our new approach, accountability for each product is clear. Each team tracks outcomes using KPIs and OKRs. Teams are ruthless about prioritization, which has made delivery more predictable.

The Pollinator: How have roles or organizational structures at BCBSMN changed as part of the shift to a product model?

BCBSMN: We've been really lucky to have a partnership with HR from the start to define new product roles like Product Managers. They've helped us restructure into Product Teams within Product Lines, ensuring that each team has the skills needed to deliver valuable results to their customers. In some areas, we have reduced layers and clarified what value each role and layer drives.

The Pollinator: What’s been the hardest part of the journey? How have you worked through these challenges?

BCBSMN: The hardest part has been overcoming resistance to change. At a company with nearly 100 years of legacy, many employees have been in their roles for decades, with long-standing expectations and habits. But as Marshall Goldsmith said, "what got us here won't get us there." Our partnership with HR has been essential to evolve culture and communication.

The Pollinator: What benefits have you seen from your new way of working? Have you seen any measurable improvements in business results or outcomes?

BCBSMN: We've seen huge gains in teams' abilities to deliver predictably. Each team that starts hyper sprints is encouraged to aim for a predictability range of 80–120%. While small two-day sprint stories can be challenging at first, teams quickly learn to size work effectively. The result is transparent, frequent delivery of incremental value. We also see teams now treating their product as a “business.” This perspective has even led to decommissioning vendors that weren’t delivering the expected value.

The Pollinator: What advice would you give to other organizations thinking about this shift?

BCBSMN: A few practical tips:

• Ground teams in the mindsets first. Practices and culture flow from there.

• Involve leadership early, build commitments, and hold them accountable to behaviors.

• Make space for teams to learn by grappling with problems.

• Empower the community to learn from each other. Transformation happens with others, not to them.

• Most importantly, build a great team and have some fun along the way!

More blossoms

The “No Differentiation” Illusion, by April Dunford

April Dunford is an expert in product and business positioning. Her fundamental approach is to help companies identify what she calls the differentiated value of a product.

In this issue of her newsletter from September 2024, she explores this question: ”How should we position a product that has no differentiation?” Her thesis: more often than not, your product is in fact different in some way from its competitors. You just need to find that differentiation. The most helpful part of her article: the chart listing why you have no differentation, what the problem might actually be, and how you might fix it. It includes examples like “value blindness” or “product pessimism.” Check it out!

Bank of England’s Digital Pound product roadmap, by the Bank of England

The Bank of England is working with HM (His Majesty’s) Treasury on plans for a digital pound, an electronic version of the British Pound currency. The bank maintains a rich website explaining the digital product strategy involved in this complex work. You don’t need to be an expert in finance to appreciate the transparency and depth of the information they’re sharing. This product strategy note, published in July, lays out their roadmap and decision points. It’s a great, public example of transparent product planning.

It’s time to prototype, by Marcus Castenfors

Here's a good article from product thinker Marcus Castenfors about prototyping and discovery and how these practices have changed with the advent of A.I. tools. His essay was inspired by a recent post on X (formerly Twitter) from a current Googler, Madhu Guru. Guru notes that Google is shifting from a writing-first to a building-first product company. You can find Guru’s tweet/xeet in Castenfors’s article.

First, I don't love how cavalierly Guru (not Castenfors, really) dismisses the steps of writing. I just don't think a writing vs. building binary is accurate or helpful, and framing writing as a “proxy” for thinking misses the fundamental point that clear writing is a form of clear thinking.

But at heart, Castenfors (and Guru) is right: prototyping is much easier with A.I., and the evolution of tools reflects this. Indeed prototyping an interface and an experience is one of the more powerful uses of A.I. that's available to product professionals. SDG has been guiding our customers through similar work lately, and it’s pretty impressive.

Finally, I appreciate how Castenfors emphasizes the craft of product in these A.I.-dominated times. I only wish he still included “writing” in his “through thinking…and sketching” in the otherwise excellent quote below.

Outside the Box

Our World In Data is a website that is absolutely stuffed with charts and graphs that explain this crazy world of ours. It’s funded by a British non-profit called Global Change Data Lab. Our World in Data includes over 14,000 charts, nicely designed and catalogued, on a variety of topics related to human life on earth. Want to know the leading cause of death in the world’s richest nations? What percentage of each continent is dedicated to agriculture? Which country has the highest percentage of its population born in another country? (The last one’s a bit of a trick question: it’s The Vatican, at 100%). Bookmark this site and use it to satisfy your curiosity.

Check it out at https://ourworldindata.org/

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 jason.scherschligt@solutiondesign.com.

• 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.

“Twenty-five year old Youth with Fur-lined Coat,” Jacopo Tintoretto. Public domain, via Wikimedia Commons.

Twenty-five years ago this month, in July of the impossibly futuristic sounding year 2000, I landed my first official product job: a role titled Online Product Manager working on the website of a major daily newspaper in a tier 3-A (but tier one in our hearts) American city.

I took the job—and, shockingly, the leaders offered me the job—even though I didn’t quite know what a product manager was. Of course, I figured I’d be managing (leading and guiding) a product (the sections of the website that I’d be assigned). But I didn’t exactly know what that job did—even though I’d be the one doing it. I quickly (or in some cases, slowly) learned that for that product at that organization, the job meant understanding complex content management issues, integrating physical and digital experiences, and prioritizing the competing needs of many different types of people (readers, advertisers, journalists, and even community leaders).

Before I landed that first product manager job, I’d spent several years writing and designing online documentation for a manufacturing software company, where I’d also gotten involved in the company’s presence on a new platform called the World Wide Web. I suppose my experience of hopping into this product manager job from another path wasn’t unique. See, product is often a job we come to sideways. It’s not a step on a linear path you pursued with clarity from the beginning; it’s instead a kind of fortuitous collision of your experience and talents against an opportunity. There may not even be such a thing as an entry-level product manager role (though Marissa Mayer may have cracked this puzzle at Google with her APM training program; see below). And I usually advise younger professionals that the best preparation for managing a product is to serve effectively in some other role on a cross-functional product team. In my case, I’d been a technical writer and web content guy. But others might arrive at the role from paths in software engineering, business analysis, UX design (a great path, by the way), product marketing, or even corporate finance.

In one of the articles I recommend below, Brandon Chu’s “The Black Box of Product Management,” Chu explores an existential question: What does a product manager do, anyway?

I’ve been thinking about that question for twenty-five years. So this week I gave myself a little challenge: how would I, in twenty-five words or less (one word for each year in the career), answer Chu’s question?

Here’s my response:

That’s twenty-five words, on the nose. I won’t explicate my entire response, but I’ll point out that it emphasizes solving problems for people and generating value for a business. That seems right.

This issue of The Pollinator features several reflections from across the product-sphere on product as a career path. While the Pollinator usually emphasizes current writing, this one includes several older pieces that are still deeply relevant.

I confess I don’t love the word product to describe the things a company produces to satisfy its users and put its mission into the world. But our language and our industry doesn’t have a better word meaning “what you make, why you make it, and who you make it for.” So product it is. Here’s to another twenty-five years of figuring product out.

On to the Garden,

Around the Garden

Get with the program

Check it out: How to make the star employees you need, by Reid Hoffman, Masters of Scale podcast, with guest Marissa Mayer

In this podcast from 2018, Reid Hoffman, co-founder of LinkedIn, argues that one of Google’s greatest products isn’t a technical innovation at all: it’s Google’s training program for associate product managers (APMs). He’s got a point.

The program, started in 2002 by legendary Googler Marissa Mayer, herself an early product manager at Google, trained hundreds of product managers who went on to great heights at Google and in other companies. In this podcast, Hoffman interviews Mayer herself. She describes her own career’s interesting origin story, explores how she uses data to make decisions, and explains why she made certain moves after Google.

The episode’s thesis: good product managers can be made. This might be challenging for companies who lack Google’s resources, but a lesson any of us can apply is to start with people of exceptional curiosity, versatility, and talent.

Reflecting pool

Check it out: How to Hire a Product Manager, and Reflecting on a Career in Product, by Ken Norton, Bring the Donuts.

These two articles by product leader and consultant Ken Norton make a good matched set. The first, which Norton published in 2003, explains his thoughts on hiring new product managers. It includes nuggets like “I’ll take a wickedly smart, inexperienced PM over one of average intellect and years of experience any day” and “much of the time your job is to be the advocate for whoever isn’t currently in the room—the customer, engineering, sales, executives, marketing.”

The second post, which Norton published in 2021, as he passed his 50th birthday, shares some things he learned throughout his long and impressive career. “Art vs. science” is an overused and even misleading binary, but The Pollinator appreciates that Norton realizes that “the art of product management matters more than the science.” Most of his reflections are based on this understanding.

Some of Norton’s wisdom product managers have heard before, but are still worth the reminder, like “fall in love with problems, not solutions” and “if you want to become a PM, look for ways to start PM’ing in your current role.” Others are new thoughts that will help the entire profession, like “hold the door open behind you.”

More blossoms

The Black Box of Product Management, by Brandon Chu, Shopify

Brandon Chu of Shopify explores the question “what does a product manager do, anyway?” Chu introduces a memorable analogy: the product manager as an API.

The article has some sweet diagrams, too.

9 lessons from my 8th year as a product manager, by Elaine Chao, Adobe

Elaine Chao, a product leader at Adobe, has established a habit of periodically posting a reflection on lessons she has learned as a product manager. This is the most recent essay, from September 2024. Our favorites of her nine lessons: “#4 Cultural change requires consistent work and reinforcement,” and “#5 Always seek to define the next level of clarity.”

Once you’ve read it, check out Chao’s other articles in the series. She does this every year. It’s a living record of an active product career.

5 women share their journey into product management and advice for others looking to enter the field, by Nancy Wang, Jenny Wolochow, Melody Liu, Terri Czerwinski, and Saummya Kaushal, The Coursera blog

This is a transcript of a wide-ranging roundtable discussion among five women working in product management careers. Four are from Coursera, the professional learning platform. The other, Nancy Wang, is an executive at Amazon Web Services. Reading the interview is like eavesdropping on a lively conversation among wise people who are doing deep work and who care about their profession.

How to Become a Product Manager and Bring Value to Your Customers, by Jessica Kent, Harvard Professional and Executive Development

Jessica Kent covers the basics here—and that’s a high compliment. This is not a reflection from a product manager; it’s a how-to guide for a product-manager—or for someone trying to become one. This piece promotes a Harvard-backed professional development program, but even if you aren’t interested in building skills through formal learning, it clearly describes the role, enumerates the skills it requires, explores the job market, and lays out the many paths to and through the career.

Product Renewal: Getting Back to Basics, from Solution Design Group’s Digital Innovation North podcast, with host Molly Doyle, featuring guest Jason Scherschligt

Solution Design Group (SDG) has started a new podcast series called Digital Innovation North, with host Molly Doyle. Pollinator editor and SDG Head of Product Jason Scherschligt is one of the first guests. Hear us talk about getting back to basics as you embark (or proceed) on a product journey.

Outside the Box

Walt Disney stole my metaphor—or did I steal his?

This YouTube video has been making the rounds lately. It shows an animatronic Walt Disney from a new exhibit at Disney World that opens later this month. Animatronic Walt describes an interaction with a child like this:

Pollinator readers will recognize the metaphor. Since its founding, The Pollinator has used pollination as a central motif.

I promise you I had never heard this Walt Disney quote when I started using the bee and pollination metaphor to describe our work. But I cannot promise you that the Disney folks haven’t read The Pollinator.

Check it out at https://www.youtube.com/watch?v=Lt4V81_LLk8

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 jason.scherschligt@solutiondesign.com.

• 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.

“Duke and ladies in a garden”- Collected Works of Christine de Pisan (1410-1411). From the collection of the British Library. Retrieved from Picryl. Public domain.

At a conference many years ago, I heard a keynote talk from web design expert Jeff Veen, author of the seminal web design book The Art and Science of Web Design and a former design leader at Wired Magazine, Adobe, and Google. Veen’s keynote featured a memorable mantra: Love the Web.

I was struck by this successful web pro’s comfortable use of the gooey word love to describe his audience’s professional relationship to the world wide web. We should love it.

But you know what? His plea made perfect sense. Still does. The web—when it’s open, standards-based, human-centered, well-structured, and accessible—is a miraculous format. It enables essential human activities like telling stories, organizing social movements, or buying socks. Like many Pollinator readers, I’ve always wanted to spend my career improving the quality of human discourse; anything else seems frivolous. That’s why I’ve always loved the web.

I remembered this talk and its “Love the Web” slogan when I recently received a LinkedIn message from someone wanting “to connect with other people who love AI.” I thought: love AI? Artificial intelligence? Who told this fellow that I love AI?

To be clear: I don’t hate AI. I surely don’t ignore it. The tech is real, powerful, and astonishing. (And yes, occasionally problematic, sometimes deeply so, like when it pollutes and deceives. Hey humans: let’s solve those problems before we give the robots control of the greatest repository of information in the history of humanity.)

In fact, every resource featured in this issue of the Pollinator touches on artificial intelligence. Here at Solution Design Group (SDG), we have some serious AI talent on our roster, and we’ve done some wonderful things to solve real problems for our customers and their customers using our Artificial Intelligence and Machine Learning capabilities.

Our AI experts here at SDG are among the most thoughtful technologists I know. They’re curious, principled, and deeply attuned to the human implications of their work. But I don’t think love is the right word to describe anyone’s relationship to this technology. We may learn from, manage, use, deploy, or even master artificial intelligence.

But love? That’s something else entirely. The object of love should be rooted in reality—a human being, a pet, a place, a story. It’s a part of human experience, not a simulation of it.

So I’ll reserve my love for my family, my dog, a few beloved lakes and rivers—and yes, for the web. Especially when it helps people understand each other better, work together more effectively, and engage in discourse that is messily, wonderfully human.

On to the Garden,

Around the Garden

Words may fail me

Check it out: The Thing You Are Expert at Will Be Your Career Downfall, from Through The Looking Glass, by Julie Zhuo

Julie Zhuo, former head of product design at Facebook, is fast becoming one of The Pollinator’s favorite writers on product. Zhuo is a successful product leader, designer, and entrepreneur—and a thoughtful, sensitive writer about technology and culture. In this recent issue of her Through the Looking Glass newsletter, Zhuo explores ideas about AI, writing, technology, and careers.

Before reading Zhuo’s perspective, I had uneasily concluded that AI tools are an inadequate substitute for the fundamental purpose of writing: turning inchoate thoughts into reasonably coherent collections of words. I think this for two reasons:

• Like many of my fellow humans, I primarily write to work out what I think, with (I hope!) some degree of nuance and depth. Doesn't AI just skip that whole thinking process? It seems to mistake "producing a written thing" for "writing." An analogy: Using AI to write is like saying the purpose of lifting weights is to push a couple hundred pounds of weights off the ground, and a forklift can do that well, so let’s skip the squats and the presses, fire up a forklift, and call that weightlifting.

• For me (perhaps not for everyone), writing sentences—fighting to find exactly the right word, in the right sequence—is a deeply satisfying activity. It's just really fun. Why would I—why would anyone—want to cede that pleasure to a computer? The analogy here? Someone who enjoys fishing can’t satisfy or demonstrate their joy by picking up a box of frozen fish sticks at the local supermarket.

Zhuo’s thesis: sometimes, yes, we write to experience a kind of pleasure, explore an emotion, or understand our own thinking. AI is not great for those use-cases.

But other times AI is in fact the best tool for the job. In Zhuo’s words, it’s “the way the wind is blowing,” so we should get over our hang-ups.

I appreciated how her essay reminded me to check my pride. Sure, sometimes it is really fun to go fishing. But when the kids are hungry and the cupboard is bare, even the most avid angler can appreciate a quick meal of fish sticks.

AI for Strategy—pragmatically

Check it out: AI and Product Strategy, by Roman Pichler, Pichler Consulting

This piece from Roman Pichler is—like most of his thinking and writing—pragmatic, helpful, and kind. Pichler here is less interested in big issues and thorny anxieties about artificial intelligence. He sets those concerns aside and offers methods and advice to help product strategists and product managers better perform their daily, demanding work.

Pichler recommends a handful of tasks that Product Strategists need done and that AI tools can do. These include:

• Conducting market research (“AI-based tools can discover user and customer trends”)

• Generating product ideas, based on customer insights

• Suggesting opportunities to differentiate the product itself with AI

• Monitoring product performance

I appreciate that Pichler’s piece recognizes limitations and real risks of AI, like environmental ethics. And he advises product pros to continue to get out of the building (GOOB), where their users and customers live. That’s one of our favorite foundational concepts.

Survey says: AI & Product Data from Figma

Check it out: Figma’s 2025 AI Report, from Figma

Thanks to Allison Lorenzo, SDG UX Consultant, for recommending this report.

The team at Figma, the popular online product design platform, recently published the 2025 edition of a report summarizing how Figma users are employing AI in their work. They surveyed over 2500 users across seven countries, mostly designers, developers, and other members of product teams.

Wisely, the report is divided into two parts: (1) how Figma users are adding AI features to the products they build, and (2) how they’re using AI in their own workflows.

Among the statistics we found most insightful:

• “34% of Figma users say that they’ve shipped applications and software that includes generative AI, compared to 22% last year.”

• “Figma users at small companies were twice as likely to say the majority of their work is on AI projects compared to those at larger companies.”

• “Over 80% of respondents felt that learning to work with AI will be essential to their future success.”

This is directionally consistent with what we’re hearing from SDG customers, too, especially those building internal tools or customer-facing features with generative AI components.

To download the full report, you’ll need to give an email address and a little personal information. There’s also a publicly available summary at https://www.figma.com/blog/figma-2025-ai-report-perspectives/.

Outside the Box

Coloring—that is, filling in black and white illustrations using crayons, markers, or colored pencils—remains a popular activity for kids and adults alike. iColoring AI is an AI-based coloring sheet generator. Enter a description of something you would like to color, and the AI will generate a downloadable coloring sheet. Warning: hallucinations happen. When I prompted it to create a coloring sheet of “a turtle and a chicken playing badminton in the park,” the turtle had an extra limb, and instead of a shuttlecock they were smacking around a little soccer ball.

Check it out at https://icoloring.ai.

A coloring sheet of a turtle and a chicken playing badminton, generated by iColoring AI

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 jason.scherschligt@solutiondesign.com.

• 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.

“Archimedes.” Woodcut on paper. Printed by Johann Petrejus,1547. Source: Deutsche Fotothek. Public domain. https://www.deutschefotothek.de/documents/obj/88960209

Here’s a great quote that’s usually attributed to Isaac Asimov, the 20th C. American scientist, science fiction writer, and futurist:

Whether Asimov actually wrote or said this is the subject of some debate. But the core idea is a powerful reminder—not just for scientists, but for product teams, too.

We product pros are, as much as anything, in the discovery business. But discovery is collaborative and incremental. We first find the problems that we are uniquely equipped to solve for our market. Then, through experimentation, prototyping, and analysis, we uncover solutions to those problems that our market will reward us for. We do this all through a process of exploration in collaboration—with designers, engineers, and other teammates working side-by-side, using their unique skills to find and then deliver the solution to our users’ problems.

People less familiar with product work might imagine that product discovery comes as a flash of great insight, like Archimedes making his legendary leap from his legendary bath and shouting “Eureka!” when he discovered the principles of buoyancy and displacement.

But I’ve worked in product for nearly twenty years, in roles from product manager to VP of product to product coach and consultant, and I can’t recall ever experiencing such a Eureka moment. I’m quite sure I have never streaked out of a bathtub in celebration of a breakthrough. But I have had countless experiences of noticing, with my teammates, unexpected behaviors or opportunities that inspire new product work. These are the That’s funny… moments that Asimov describes.

And I love how the Asimov quote usually is expressed with trailing ellipses: it’s “That’s funny…” and not merely “That’s funny.” With those ellipses, That’s funny… does not end; it leads to something else. I see product work in those ellipses.

For example, check out how these statements can lead to new insights, new solutions, and better products and businesses:

• That’s funny…our onboarding screen for new users is confusing to our veteran users.

• That’s funny…users are searching for “delete account,” but we don’t offer that feature.

• That’s funny…we shipped that improvement and no one noticed.

• That’s funny…B2B customers want to see prices before they add options, not after.

Observation and responses to those observations are skills your product team can sharpen. A fun exercise for a cross-functional product team: write some That’s funny… statements about your own product or your own users. A team can do this in a quick thirty-minute exercise with a whiteboard, a pack of post-it notes, some user insights (interview transcripts, support tickets), and some imagination. As you collect your That’s funny… statements, ask yourself: What’s surprising? What’s underexplored? Where could these ellipses lead?

On to the Garden,

Around the Garden

We achieved PMF! But what is it?

Check it out: “What Startups Get Wrong About Product-Market Fit” from Close.com’s “0 to $30 Million Blueprint” podcast series

Close.com is a successful modern CRM product and business. They do something we admire here at the Hive: they openly share insights from their product journey with their customers and the broader product and business community. In this article, podcast, and video, Close’s CEO and founder, Steli Efti, is interviewed by Desiree Echevarria on a topic of interest to any product team: reaching Product-Market Fit.

Product-Market Fit, or PMF, is that elusive but essential milestone that indicates a business has found—or discovered—the product that meets its market. Product thinkers have written and chattered extensively about the characteristics of PMF.

The conversation between Efti and Echevarria is among the more insightful discussions of this topic that we’ve encountered. Efti explains that PMF is evident when there's more demand than the startup can handle:

Efti also cautions against mistaking early traction for PMF, noting that temporary sales boosts can be misleading. True PMF involves sustained customer retention and enthusiasm, where the product becomes integral to the customer's own processes, rhythms, and operations.

Desiree Echevarria and Steli Efti discuss product-market fit

Internal Medicine

Check it out: Product Strategy for Internal Products, by Kent McDonald, Inside Product

A company’s product leaders—rightly—prioritize customer-facing products when developing product strategy. Here Kent McDonald of Inside Product addresses a common oversight in many organizations: the lack of a defined product strategy for internal tools and systems. Teams working on these internal products, like HR platforms, finance systems, or internal dashboards, frequently operate without this clarity, leading to misaligned efforts and suboptimal outcomes.

McDonald suggests that internal products deserve strategic love, too. I like how he describes a clear product strategy’s value as a decision-making filter that enables prioritization. Internal teams will operate more effectively with this filter in place. And internal products have a way of becoming customer-facing experiences.

For organizations aiming to improve their internal systems, McDonald's article serves as a valuable reminder: internal products are not just operational necessities but strategic assets. Applying thoughtful product strategy to these tools can lead to more efficient operations, better user experiences, and ultimately, a more agile and responsive organization.

Merholz on Design Leadership

Check it out: Design Leadership & Org Design (feat. Peter Merholz). Nielsen-Norman Group UX podcast episode. Recommended by Jared Johnson, SDG UX strategy consultant

Jared Johnson, SDG Design Strategy Consultant, offered the following summary and analysis of this Nielsen-Norman Group podcast episode, featuring Peter Merholz.

This volley of ideas between Therese Fessenden and well-known design leader Peter Merholz is a great listen for any team looking to deepen their understanding of user needs and improve how they deliver digital products. From scaling research functions and mapping service blueprints to creating emotion-invoking experiences, the energetic conversation with a deeply experienced leader like Merholz highlights how organizations can intentionally inform the next iteration of a solution.

Merholz emphasizes the importance of intentional product leadership—structuring teams with care to balance speed, quality, and cost. His distinction between “UX” and “design” is both sharp and reassuring. UX, he argues, is the responsibility of everyone involved in product development and even across the greater company. Design, by contrast, is a focused discipline—”a distinct contributor to this outcome that is user experience,” as Merholz says. It is the structured process of research, iteration, feedback, and delivery that shapes how users experience a product or service.

I very much appreciate this perspective. It aligns with thinkers like Jared Spool, who’ve long argued that everyone is a designer. Developers, marketers, salespeople, and product managers all have a role in shaping the user experience. That’s why it’s so important for product and UX teams to align on user insights, jointly validate ideas, and balance user needs with business goals.

Well done, NN/g—and thanks as always to Peter Merholz for the inspiration and insights.

Outside the Box

Earlier this month, on May 20, the bee-keeping world celebrated something called World Bee Day. As you know, bees are a central motif in the Pollinator’s lore (and logo!). We think gardening is a great metaphor for product work, and pollinating critters like butterflies and bees inspire our mission of cultivating product wisdom and insights in and beyond our SDG product community.

World Bee Day is no mere greeting-card holiday: it’s officially recognized by the United Nations. It was first proposed by the apiarians of the European nation of Slovenia. So to celebrate World Bee Day, we suggest you check out what the Slovenians have to say about it.

Check it out at: https://www.gov.si/en/registries/projects/world-bee-day/.

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 jason.scherschligt@solutiondesign.com.

• 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.

Scribe working on a manuscript, surrounded by his research material. Jean Le Tavernier, Public domain, via Wikimedia Commons. After 1456. Source: https://commons.wikimedia.org/wiki/File:The_Scribe_at_Work.jpg

How weird is this? Product management is a job function that even its own practitioners immediately reframe as another job function.

You’ve all seen this, I’m sure. Many have argued (though I’m not so sure) that the product manager is like a CEO, but for a product. American football fans (Skol!) might say a product manager is like a quarterback, but for a product team. To reflect the breadth of the work, some product leaders have suggested that a product manager is something like a film director. And here’s one we use throughout the Pollinator: a good product manager is a gardener.

I blame the phenomenon on the imprecision inherent in the work’s two words, product and management. Product is broad and squishy; management is even broader and squishier. So to make sense of it, we describe product management using other jobs that are concrete. My 81-year-old mom knows what a quarterback does; she doesn’t quite believe that product management is real.

One job-to-describe-this-job that we don’t hear as often, but I think is especially apt: the product manager is an editor. More than a decade ago, when the Web still felt fresh and full of hope, entrepreneur and product investor Andrew Chen wrote a brief essay called Why Companies Should Have Product Editors, Not Product Managers. In it, Chen quotes Jack Dorsey, former head of Twitter:

This framing helps me understand product work. Among the wide and various skills necessary for a product manager, near the top are editing skills—and not just of language. (Though, yes, it is essential that both the product manager and the editor write well.) A skilled product manager understands narrative, explores possibilities, makes a case, clarifies through language, plans an experience, and helps other professionals do their best work

Can you make a convincing argument? Can you find a thread that coheres parts? Can you resolve a conflict? Can you bring order and clarity to chaos? Can you identify an extraneous element—and are you brave enough to excise it, even if you love it? That’s what a good editor does—and it’s what a great product manager does.

The list of product artifacts is long: roadmaps, user stories, capacity charts, metrics reports, timelines, research materials, user profiles, and—if you’re doing the job well—a healthy P&L. But as important as any of those artifacts is the narrative of your product. A great product is a great story, and its hero is your user, a person with a problem that your product can solve. The wise product manager edits this story to make this hero succeed.

On to the Garden,

Around the Garden

When probability fails

Check it out: “Revisiting Subjective Probabilities” from The Uncertainty Project

Those of us who naturally think and work in narratives sometimes suppress our imaginative instincts and try to construct a rational, mathematical model for product and business decisions. “I should analyze this with numbers—maybe even convert it to dollars,” we think, uneasily. “That’s what colleagues expect, right?”

If you're like that too, you might feel the relief of validation when you read this article from the wise gang at The Uncertainty Project. The article is rooted in the principles of a 2020 book called Radical Uncertainty, by John Kay and Mervyn King. That book, and the Uncertainty Project’s examination of it, points out that probabilistic methods (Bayesian logic, for example) may not be the best tools for making decisions in large, complex contexts.

The alternative? Imaginative techniques, like a good story or thoughtful narrative about a user problem. For example, King and Kay recommend that decision-makers (like product managers) construct a good “reference narrative,” and update it as they develop new information.

Once again, we see that storytelling skills are product skills. The product manager’s instinct for narrative may be exactly what a decision demands.

A new cube in your toolbox

Check it out: “The Critical Link Between Product Management and Business Strategy,” by Alexandre Luis Prim, California Management Review 

I know, I know: you don’t really need another product diagram or framework. Your toolbox is full.

But if you can make some room in there next to the North Star framework and your shopworn Jobs-To-Be-Done template, consider adding this tool from Brazilian product expert Dr. Alexandre Luis Prim, published by the Haas Business School at The University of California-Berkely.

The cool thing about Prim’s model: it’s three-dimensional. A product’s outcomes are aligned to business objectives through a standard grid, with columns and rows. But initiatives are expressed through a z-axis, connected to each node in the product and objective grid. He visualizes these three dimensions as a cube, segmented like a Rubik’s Cube. Prim calls this the “Product-Objective-Initiative Cube,” or POIC. It looks like this:

The Product-Objective-Initiative Cube, by Dr. Alexandre Luis Prim

Prim’s article also includes an example of applying this model to real business problems. And it’s illustrated with charts and tables that demonstrate how a manager can connect initiatives to business objectives, via product. We appreciate Prim’s advice on implementing the model pragmatically:

Prim’s POIC may not be your everyday tool, but for specialized situations on complex product portfolios, this cube might be the exact device you need.

An underappreciated product career path: technical writing to product management

Check it out: Transferrable skills: Technical Writer to Product Manager, from the Pink-Haired Content Strategist

This post on Medium, from a writer who calls herself the Pink-Haired Content Strategist, was especially resonant for me: I too started my technology product and content career as a technical writer. That’s right: thirty years ago, I was writing installation guides, maintenance manuals, online help, and interactive tutorials. My first gig was writing the service and maintenance manual for a huge mail processing machine used by the US Postal Service. I still think I could change some of the belts on that thing, because I’m the guy who wrote the instructions and drew the diagrams explaining how to do it.

I always appreciated the way tech writing established a good foundation for my own product career, especially when I moved from mail machines to software products. As the young guy writing a technology’s products online help and training materials, I got to spend time within software design and development teams, learning how different talents interact. And writing documentation is a great way to understand how a product’s users think and what users expect a product to do.

The Pink-Haired Content Strategist identifies these and other profound connections between a technical writer’s skillset and a product manager’s responsibilities. Chief among them: curiosity and empathy with a user.

I often say that the best entry into product management is playing another tactical role on a cross-functional product team. That role is often an engineer, a designer, or a researcher. But as the Pink-Haired Content Strategist reminds us, it also could be a writer. After all, the skills that make great technical communicators—clarity, curiosity, empathy—are also the skills that make great product people.

Note: Transferrable skills: Technical Writer to Product Manager is paywalled on Medium. If you aren’t a Medium paid user and would like to learn more about the article, let me know in the comments or via email.

Outside the Box

If you enjoy cooking, you’ve no doubt discovered that recipes on many foodie websites are cluttered with lengthy personal stories of the recipe-writer. You want my recipe for pasta carbonara? First let me tell you about a lost weekend I spent in Rome. I was wading in the Trevi fountain when I met a mysterious swineherd…

While sometimes these reflections are entertaining and insightful (remember: at the Pollinator we appreciate narrative), more often than not they block the user from their goal. I’m hungry, and I don’t know what to do with my noodles, pork cheek, Pecorino Romano cheese, and egg. Can’t you just give me the ingredients and instructions?

Just The Recipe addresses this problem deftly. Paste in any URL of a Web page containing a recipe, and Just The Recipe will parse the page and return the recipe itself, nicely formatted and stripped of ads, stories, and Roman fountains.

Check it out at: www.justtherecipe.com.

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 jason.scherschligt@solutiondesign.com.

• 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.

Illustration of Sacajawea guiding the Lewis and Clark expedition through the Rocky Mountains. Alfred Russell, 1904. Source: Internet Archive Book Images, No restrictions, via Wikimedia Commons

I’m always seeing examples of good product thinking and practices in unusual places. Surely others in the Pollinator community are weird in this way that I’m weird.

For example, those folks involved in the Louisiana Purchase and the Lewis & Clark expedition in the early 1800s? I learn about them and I think: man, that was a great cross-functional product team.

Americans who paid attention in 7th grade probably know this chapter of US history. In the early 1800s, President Thomas Jefferson, displaying considerable foresight, recognized the value of the vast western portion of the North American continent, then called the Louisiana Territory. Jefferson negotiated the purchase of that territory from France. He then established a national priority with long-term potential, though not a lot of short-term benefit: explore the newly purchased territory; establish relationships with the indigenous people who had called that land home for centuries; and find a route to the Pacific Ocean. He secured funding from Congress and appointed a couple of capable explorers, Meriwether Lewis and William Clark, to lead the expedition.

But even with their authority and resources, Lewis and Clark needed something more: expert guidance. Early in their journey, they made a critical addition to their team, engaging a phenomenal guide with deep knowledge, incredible endurance, and an impressive variety of skills: a young Shoshone woman named Sacagawea.

For three years, Lewis, Clark, Sacagawea, and their team journeyed from St. Louis, MO to the Pacific Ocean and back. Along the way, they relied on the knowledge and generosity of many Native nations, whose contributions were critical to their success, even as the expedition foreshadowed dramatic changes for their communities in the coming years. And 219 years ago this week, on March 23, 1806, they said goodbye to the Pacific coast and began the long journey home.

The analogy of this expedition to our product work is a bit on the nose, sure, but I think it works. Concepts need vision, funding, and executive support. Leaders set direction and make key decisions. Teams need adequate resources and funding. Strategic partnerships can help a team reach its goals. Obstacles will be encountered, but we anticipate them and deal with them as they arise. And success depends on teammates leading in their domains, with deep expertise and skill.

Every day, the Lewis & Clark & Sacagawea expedition faced challenges: rivers to ford, mountains to scale, weather and wilderness to endure, and encounters with indigenous people with differing perspectives on the expedition’s presence and purpose. I like to imagine that the clarity of the mission’s purpose helped guide the team’s daily decision-making. We’re facing an obstacle? Let’s make sure we’re still headed west.

One more thing. That expedition’s official name was perfect for a contemporary cross-functional product team: they were called The Corps of Discovery.  

On to the Garden,

Around the Garden

A Unified Model for Product Making

Check it out: A Blueprint for Modern Product Development, Sam Quayle, Hyperact

We've mentioned this small British product consulting firm called Hyperact in past issues of the Pollinator. Here at SDG we’re consistently impressed by their content on product models and systems.

Hyperact just published this article with an ambitious title: A blueprint for modern product development. Any unified theory of product-making is going to be both incomplete and somewhat biased, but this is one of the better ones we've seen.

The article is thorough but accessible, with practical tips (“Don't just wait for opportunities to come to you. Regularly schedule time for proactive exploration of user needs, market gaps, and technological opportunities.”) and pitfalls to avoid (“Pitfall: Trying to be too scientific — You're not going to be able to truly validate hypotheses until you've shipped the real thing.”)

We especially appreciate the inclusion of a comprehensive diagram that lays out all the stages of their blueprint. You can download a high-res .PDF version within the article itself.

Highlights of the diagram:

• The "capture" step is a great way to describe the start of product-making. That’s where info is collected and understood, resulting in opportunities.

• Including "Later / Next / Now" to reflect the stages of a typical Now / Next / Later roadmap is a simple and clever inversion. When we’re capturing, it’s for later.

• The list of activities is helpful, though certainly incomplete.

• Our favorite bit: the "wrap-around" suggested by the fade-in and fade-out treatment of the graphics in the Focus row. That’s a visual cue that the rolled out product will generate new insights and opportunities, continuing the cycle.

Opportunity, Arise

Check it out: Ask the Community: Tracking Opportunities Not Related to Your Outcome, Teresa Torres and Melissa Suzuno, producttalk.org

Teresa Torres of Producttalk.org speaks and writes frequently on product topics. She’s well-known for a framework called Opportunity Solution Trees and for the book Continuous Discovery Habits.

We appreciate how Torres has built a community of product leaders and practitioners at her website, Producttalk.org. Participating in the community requires a paid membership. (Side note: excellent content on the Web often requires readers to pay for it. That usually means it’s worthwhile! Side note to the side note: The Pollinator is both excellent and free.)

Torres and her team occasionally share highlights of community discussions on their free public website.

They recently explored a situation that The Pollinator’s outcomes-driven community might encounter: what should product leaders do when you uncover an opportunity that isn’t related to the outcome you’re driving? In this post, the producttalk.org community shares a variety of techniques for dealing with this situation. This is practical, actionable advice, from real-world product managers facing real product challenges. Torres herself concludes the article with a good tip for organizing and collecting these opportunities.

The Language of an AI Hallucination

Check it out: A Hallucinogenic Compendium, Eryk Salvaggio, Cybernetic Forest

This 2024 essay explores how Large Language Models (LLMs) appear to “speak,” by exploring how they appear to “think.” In doing so, it seeks a new vocabulary for describing how AI works—because terms like speaking and thinking and writing aren’t quite right.

I should acknowledge that I approach these issues as a guy with a deep interest in and sensitivity toward language and communication systems. I struggle to consider text produced by AI engines to be “writing,” because, to me, the process of writing is not merely the outputting of textual content, but the process of decision-making, word-by-word, by which you work out what you think about a topic. AI-generated writing seems to skip these essential decision-making steps and jump right to the output part. In a way, it’s the opposite of writing.

Salvaggio explores these questions by addressing the relationship between LLMs, language, factuality, and, yes, product. I found the piece oddly reassuring. For example, check out how he describes the text produced by LLMs:

This passage describes as well as anything why I struggle to think of text generated by an LLM as "writing." It looks like writing, but that's an interface trick. Thank you, Mr. Salvaggio.

Self-promotion: Don’t get ensnared by your requirements

Check it out: The Requirements Trap, Jason Scherschligt, Solution Design Group, presented at Minnesota PDMA Chapter, February 2025

On behalf of Solution Design Group, where I’m a proud employee-owner, I recently gave this talk sponsored by the Product Development and Management Association, Minnesota Chapter. My talk’s thesis: product teams who strictly follow a requirements-driven product model are at risk of failing to meet their primary objective: to deliver value to your customers and your business.

A recording of the session is now hosted on Vimeo and available via the PDMA MN’s website, under the Past Events section. If you can stand to hear me ramble for nearly an hour on this topic, Pollinator readers might appreciate it.

Excerpt from “The Requirements Trap,” a talk delivered by Jason Scherschligt (SDG) and sponsored by PDMA, Minnesota Chapter.

Outside the Box

If you ever think: man, I need to feel insignificant, this is the website for you. 100,000 Stars is an interactive exploration of the relationships between over one hundred thousand stars, including our own Sun. It was created by a team of “space enthusiasts at Google,” as an experiment to test the capabilities of the Chrome browser. (The Pollinator can’t verify its performance in other browsers). You can zoom in, zoom out, traverse deep space to new clusters, and feel comfortably, reassuringly tiny.

Check it out at: https://stars.chromeexperiments.com/

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 jason.scherschligt@solutiondesign.com.

• 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.

“Cod and Gurnard.” Utagawa Hiroshige. 1830s. Minneapolis Institute of Art. Public Domain. https://collections.artsmia.org/art/61400/cod-and-gurnard-utagawa-hiroshige

I recently was the featured speaker at an event sponsored by the local (Minnesota, USA) chapter of the Product Development and Management Association (PDMA). My topic was how teams and businesses can get trapped by their requirements-based models and processes.

The situation I described looks something like this: a business identifies a challenge or problem, someone smart thinks up a clever solution, and that solution is considered during an annual planning process. Eventually a project gets funded, and one of the first things that happens is requirements are “gathered.” This triggers a chain of events where a well-meaning, talented team iterates on these requirements until the product is released. The team may perform really well, delivering the requirements, on-time and on-budget—but they also may fail to actually solve the business problem.

Why does this happen? It’s complex, but I think businesses often get snared in this trap because they operate in a context—a milieu, if you don’t mind a little French—where estimating effort and then defining requirements of a solution they determined up-front is the only way of operating that they know.

To illustrate this pattern, in my PDMA talk I shared a modern parable you might be familiar with. Two little fish are swimming along in the ocean. They meet a friendly bigger fish who smiles and says, “How’s the water, boys?” As the big fish swims away, one little fish turns to his buddy and asks, “What is water?”

The late writer David Foster Wallace used this story in a memorable graduation speech at Kenyon College twenty years ago. It’s reprinted in a brief volume called This Is Water: Some Thoughts, Delivered on a Significant Occasion, about Living a Compassionate Life. You should read the speech—but only after you’ve finished this issue of The Pollinator, of course.

The tidy moral is that when we’re deeply embedded in a certain environment, like a fish in water, that environment is all we know, so we aren’t even aware of its influence on our thinking and our behavior. We might not even know that context exists. So a business might not realize there are entirely different ways of working, beyond the water—ways that aren’t requirements-driven or project-based. Ask them about their operating model, and they might just say, “What’s an operating model?”

Effective product teams (and entire organizations; this problem is bigger than the product team!) will consider their own assumptions about how value is generated. They’ll spend a lot of time in the problem space. They’ll operate with agility in discovery, not just development. They’ll get to know the cast of characters—users, customers, stakeholders—affected by their products. They’ll reframe (and fund) a team—not a project—as the mechanism for generating value, shifting their focus from outputs to outcomes.

They’ll inspect and identify their own water.

On to the Garden,

P.S. By the way, that PDMA event seems to have garnered many new Pollinator subscribers. Welcome, newcomers! The water here is just lovely.

Around the Garden

Identity crisis

Check it out: Identifying your org’s digital products, Jeff Patton, Jeff Patton & Associates

A challenge that product leaders know all too well is defining what their products actually are. It sounds simple, but in many organizations—especially those that don’t sell digital products directly—it’s surprisingly difficult to draw clear boundaries around what constitutes a "product." We explored this challenge in past Pollinators, like Setting the edges, in the October 2024 issue.

Jeff Patton, a renowned product development thinker and consultant, tackles this challenge head-on. In this 2024 article, Patton introduces a “decomposition model” to help teams break down their ecosystem into distinct product layers. Using the example of a bank, he defines five levels of products:

• End products

• End-customer enabling products

• Employee enabling products

• Product team enabling products

• Partner enabling products

By working through these layers, teams can better identify what their products actually are—and who they truly serve.

Our favorite passage comes early in Patton’s article, where he urges product managers and teams to start by thinking about customers and users who must get value from the product:

Start with the customer and user, and you will always have The Pollinator’s heart.

This world we occupy is an inspiration

Check it out: The Secret to Innovative UX: Look Beyond the Digital World, Rodolpho Henrique, UX Magazine

I’m a bit skeptical of any advice that claims it offers “the secret” or “the cure”—that sneaky definite article the indicates a mode of discourse that always puts me on alert.

But then I read this recent article from designer Rodolpho Henrique and thought: if this isn’t the secret, at least it is a secret to innovative UX.

Henrique advises UX and product designers to draw inspiration for their work from the analog realm (you know, this thing I call “reality”). By carefully observing patterns and practices in architecture, nature, and physical product design, designers can inject fresh thinking into their work, resulting in more intuitive and user-centered digital interfaces. For example, to Henrique, the principles of ergonomics and wayfinding—common considerations for designers of physical objects and spaces—are also vital in digital contexts.

Henrique’s thesis? By integrating insights from the physical world, UX professionals will craft digital products that are not only functional but also deeply engaging and aligned with natural human behaviors. He’s right, of course. Henrique's perspective reminds us that innovation often stems from interdisciplinary exploration and a willingness to look beyond traditional boundaries. And maybe that is the secret.

Roadmap as story

Check it out: A simplified product roadmap storytelling framework, Noa Ganot, Product Coalition 

Two things I’m a sucker for: a product roadmap framework, and an origin story of a product career that begins in the arts and humanities. Noa Ganot, an Israeli product consultant and leader, offers both here.

Ganot roots her approach to roadmapping in her own professional and personal interest in theater. A recent re-exploration of this discipline helped her strengthen both her acting and her product management, since in both domains, you “need to be willing to ponder, live with unclarity for a while, and keep exploring.”

(Tangent: I honestly think some smart tech recruiter should build a business recruiting product pros from theatre and music scenes. It’s such an untapped source of latent product talent. You’re welcome, recruiters.)

Then, Ganot describes a framework called GOSPA, which is based on her storytelling training and skills. GOSPA stands for Goals, Original plan and assumptions, Status, Position, and Action plan.

I think the differentiating feature here is the O element, for Original plan and assumptions. A lot of roadmap advisors recognize that a roadmap is a living document reflecting a current intent, and that roadmaps can change. But by including the original plan as part of the narrative, Ganot enables roadmappers to connect changes to the product’s origin. It’s a technique that tells an honest story while allowing space for learning and growth.

I plan to add GOSPA to my toolkit. Pollinator readers should too.

Outside the Box

Massive Science is the kind of website that reminds me of the old web, the web I first loved. It’s a digital publication with accessible writing from real working scientists on a wide range of scientific topics. One part media platform, one part educational resource, and one part citizen journalist outlet, Massive Science describes itself as a “science storytelling community” populated by “scientists telling stories about all the truth and beauty in the universe.” If that’s not a worthwhile mission, I don’t know what is.

Check it out at https://massivesci.com/.

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 jason.scherschligt@solutiondesign.com.

• 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.

Adam And Charles Black. The Solar System. [Edinburgh: Adam and Charles Black, 1885] Map. Retrieved from Library of Congress at https://www.loc.gov/item/2013593146/. Public Domain.

Consider this remarkable Earth upon which every Pollinator reader resides. It rotates and spins; it even wobbles. These concurrent motions, plus the Earth’s axis’s convenient 23.5 degree tilt against the sun, give us remarkable things like seasons and weather. As I write this introductory essay, the temperature here in Minneapolis, Minnesota, USA lurks well below zero degrees Fahrenheit. That frigid temperature affects things. Just ask my dog.

Many businesses and therefore products are profoundly affected by industry-specific seasonal cycles. These cycles can—or should—influence product decisions and priorities. Some I’ve seen in my own career and life:

• An online university adapts its user experience to match a school quarter and school year cycle.

• An agtech firm’s agronomist customers will need new functionality timed to match the spring planting or fall harvesting seasons.

• An accounting product must update tax tables and calculations according to annual filing deadlines and annually updated regulations.

• A company providing services and technology to fishing guides, golf courses, and ski resorts delivers features to match the seasonal cycles of those hobbies.

Your business or industry may be influenced by other seasonal cadences. How do you align those cadences to your product planning, prioritization, and releases?

Several years ago, when leading product management and design for a company in an industry deeply affected by seasonal cadences, I maintained a simple data table that depicted the relative focus of our primary users during each month of the year. You can make your own in a few minutes with an Excel worksheet and an area chart.

Here’s an example for a fictional business that provides digital tools and services to help school administrators manage K-12 schools. Those users have quite different needs throughout a year, depending on where we are in a school year cycle. This is an area chart I generated in Excel for such a business (again: this chart is both fictional and overly simplified).

You can probably see how this simple visualization might help a product manager determine when to deliver new functionality to help the school staff prepare, for example, for summative annual assessments, which usually take place in the spring.

Now here’s the important thing: these seasonal cycles of your customers and your market may not align with your own business’s fiscal year, or with product planning and funding cycles that fit that fiscal year.

Right now, in January, many businesses might default to resource allocation decisions that prioritize the funding established for the new calendar and fiscal year. “Hey, let’s hit those 2025 delivery goals. Of course you’ll start with the biggest thing we funded, won’t you?,” say your well-meaning colleagues. But they may not consider how those priorities align with the seasonality of your market.

As always, the wise product professional, like The Pollinator’s readers, starts by considering your users. Know their rhythms. Live in their seasons.

Your product and business will be better for it.

On to the Garden,

Around the Garden

Cracking Product-Market Fit

Check it out: First Round Review’s Product-Market Fit Method, First Round Review

First Round Review is a newsletter and editorial platform from First Round Capital, a venture capital firm. A lot of its best content is targeted squarely at product leaders and teams of any funding structure or maturity stage. Their Product-Market Fit Method website is a detailed resource for product leaders looking to make the leap from idea to impact by reaching that most elusive but essential milestone: Product-Market Fit (PMF).

The website is partly a content marketing piece promoting or possibly accompanying a recurring in-person retreat. Selected applicants can fly to California and enjoy four days of intense content and immersive programming with other early-stage product leaders. Admittedly, that may be part of the reason I found this guide valuable. When you’re a Minnesotan in January, words like “Sonoma” and “Wine Country” have a certain appeal, no matter where you are in your journey to PMF.

But even if you have no intention of applying for the retreat, the content on this Product-Market Fit Method website demystifies the process of uncovering a product that fits its market. You’ll find actionable frameworks, hard-earned lessons, and tactical, take-able advice, like this:

Whether you’re just working from a napkin sketch of a product idea or are leading product for a well-established enterprise, check it out.

Are you down with AOP?

Check it out: Annual Operating Planning (AOP): A Practical Guide for Product Leaders, Jim Morris, Product Discovery Group

Product Discovery Group’s guide to annual operating planning (AOP), written by Jim Morris, is a helpful map of a process that we product folks can find challenging, even maddening. The Pollinator Perspective on this process: annual planning is valuable, but it often struggles to meet the dynamic realities of product development. This guide is especially useful for the season-sensitive product manager, who might be nobly striving to bend her employer’s annual funding process to fit a product-driven, iterative discovery and delivery model.

The article lays out a structured approach to aligning cross-functional teams, defining measurable outcomes, and prioritizing with focus. Morris wrote it after facilitating a roundtable with leaders who reflected on the challenges of reconciling annual planning with responsive delivery. We liked his advice about balancing flexibility with precision:

Like any description of a process, it’s best read with a shake of skepticism and a hearty dose of adaptability. Still: it’s well-organized, well-written, and well-worth reading.

Internal products deserve love, too

Check it out: Design Tips for internal products, Kent McDonald, Inside Product

Kent McDonald’s brief, clear Design Tips for Internal Products addresses a subset of digital product design where SDG spends quite a bit of time: designing software that’s used by a business’s internal users. McDonald shares practical advice for designing internal products that are not only functional but also user- and business-friendly. Much of his advice is immediately applicable, like this bit of wisdom:

We like how that advice can be converted into a metric that is meaningful for a particular user persona.

As with much advice in this domain, the clarity of McDonald’s tips may belie the complexity of execution. Designing for internal teams often comes with tight timelines, limited budgets, and competing priorities, which aren’t always easy to reconcile. While McDonald’s tips are valuable, you’ll still need to consider how to navigate organizational constraints and make tough trade-offs.

Wandering the Garden: Minnesota PDMA event

I (Jason, editor of The Pollinator) will be the featured speaker at an upcoming session sponsored by the Minnesota Chapter of the Product Development and Management Association. My topic: The Requirements Trap: Are Your Requirements Sabotaging Your Success?

The session is virtual, and it takes place on Wednesday, February 19 at 5:30 PM Central time. See details and register here.

Outside the Box

Library Extension is a simple web browser extension for Chrome, Firefox, and Edge that recognizes when you’re browsing a web page that contains details about a book—for example, on a site like Amazon.com, Goodreads.com, or BarnesandNoble.com. Once configured, the extension adds a content module to the page showing whether that book is available at your local library. It’s almost like a book merchant’s detail page is showing you how to get your hands on a book without buying it from them. Readers and other library-lovers are sure to appreciate it.

Check it out at https://www.libraryextension.com/.

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 jason.scherschligt@solutiondesign.com.

• 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.

“Apples, grapes, pears and strawberries in a porcelain bowl and other fruit on a stone ledge with a goldfinch and various insects,” Johann Amandus Winck. Public domain.

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:

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

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.

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

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:

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.

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 jason.scherschligt@solutiondesign.com.

• 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.

The Ghost Story, Walter MacEwen, 1887, Cleveland Museum of Art. Public domain

Product management is a strange way to spend one’s days, isn’t it? The career defies categorization; it even resists definition. Product management is technical; it is business; it is marketing; it is design; it is leadership. It is also not technical, not business, not marketing, not design. And as for leadership? A product manager needs to be a strong leader, surely—but of systems and missions, not of a corner of an org chart.

You think you understand product management’s boundaries, but when you reach for it, it is ungraspable, like a ghost.

A product manager coordinates, but is not a coordinator. A product manager makes, but is not a maker. A product manager researches, but is not a researcher. And product management, as a set of practices and responsibilities, exceeds the product manager’s job, much like customer service exceeds a customer service rep’s job.

Perhaps the best analogues for the work are orchestra conductor, gardener, shepherd, or expert guide. But of course, no sheep-herder ever tended a garden while guiding a tour and cueing the string section for its second movement entrance.

I think product management is a job for systems thinkers who are deft communicators, curious polymaths, and skeptical optimists. Product managers operate within tensions. You need ambition, but don’t let that devolve into ego. You must genuinely like people, but you should be willing to defy them. You should be flexible on many things, and really stubborn about a few others. Your head may be in the clouds, while your hands are in the dirt.

If you can hold contradictory ideas in your brain at once, if you can zoom into details (why isn’t that button following the pattern we’ve established?) and zoom out to broad strategy (how could we adapt our product to serve this adjacent market?), then product management is a role where you can thrive.

Done well, product management is one of the most important functions in a contemporary company. Done really well, it might even dissolve into the company, so that the product manager’s skills and ways of operating are activated within the more concrete roles on a team. Sometimes I think the ideal product manager is not one skilled person on a team of many skilled people, but a spirit who haunts the entire team. Perhaps that’s the best analogue of them all.

On to the garden,

Around the Garden

The organization as a blob

Check it out: A simple model of constructivism in organizational change, from the Expatriate/Ex-patriot blog 

The phrase “model of constructivism” from this article’s title might give you flashbacks to a social sciences Gen Ed course you barely passed as a college freshman. But the article is actually a refreshingly accessible analysis of how an organization’s members create that organization’s structure and decision-making paths.

The writer, an agile coach and organizational effectiveness consultant named Heather (her blog doesn’t indicate her surname), notes that she “like[s] applying theories of political science to patterns of development and management in companies, especially when it comes to agile practices and change management.” Her blog is populated with excellent reflections on this theme.

In this recent post, Heather argues that an organization’s actual systematic functioning is less rigid than its formal structure, as depicted in org charts or process documents. In fact, the members of an organization are the ones who continuously create the organization’s structures and processes. In other words, the members “construct” the organization, in a shape that’s more amorphous than the formal structure.

While this post never mentions product management, it does explore ways to navigate change, overcome resistance, and optimize for value—which product leaders need to do often, and well. So we can apply Heather’s constructivist approach to the challenges of implementing a product model.

That application looks something like this:

• An org attempting to deliver value through product will not succeed by merely mandating product methods from the top or dropping in new roles or frameworks that a consultant recommends.

• Instead, to implement a product operating model, a product transformer should inspire new thinking and ways of working through stories and culture.

• By doing so, a product transformer can influence an organization’s members so that they construct (conceptually) a product-driven org.

• To do this well, look for places where the documented org structure and the “constructed” organization are incongruent. Work on those incongruencies to overcome resistance to the new model.

It’s an intriguing way of approaching any kind of organizational change, including a change to product models. Has any Pollinator reader tried such a technique?

A newsletter series we’re tracking: product anti-patterns

Check it out: 10 anti-patterns for product managers, by Marcus Castenfors

In August of this year, Stockholm-based product coach Marcus Castenfors started writing a series of newsletter articles on common anti-patterns in product management. He’s promised to tackle ten of them; as of last week he’s published six.

Anti-patterns are common models and behaviors that might seem benign, but that actually are ineffective or downright counter-productive. Examples that Castenfors has written about to-date include Giving too much autonomy too soon and Focusing on parts rather than the whole.

Castenfors is a skilled storyteller who is ready with an anecdote or insight that clarifies his concepts. He’s also a talented illustrator, and these posts are peppered with colorful drawings and diagrams that illuminate the text. Here, for example, is Castenfors’s illustration of a dependency map, a tool he recommends to overcome the anti-pattern of “pushing dependencies to the side.”

Dependency map illustration, from “Antipattern #4: Pushing dependencies to the side,” Marcus Castenfors

We’ve subscribed to the newsletter, and expect we’ll be following the series to its conclusion.

How Gitlab does product

Check it out: The Gitlab Product Handbook, published by Gitlab.

One of our favorite subgenres of product and technical content is publicly available documentation of other organizations’ product practices, standards, and processes. You can learn so much by inspecting how successful companies think about product management, design, and development.

The folks at Gitlab, a popular web-based DevOps platform, maintain a really great handbook on their own product principles, processes, and organization.

The entire handbook is worth reviewing, but the brief section on product principles is what first caught our eye. Most of the principles can apply to any product organization. They’re expressed as brief sentences, and accompanied by links to external resources that explain the concept. A few of our favorites of Gitlab’s principles:

• Always be learning (#3)

• You’re not the customer (#4)

• Assume you are wrong (#7)

Other sections worth reviewing include Iteration Speed and Product Excellence and Drive Product Usage. The latter reinforces that a Gitlab product manager’s job is to make sure the product’s users are getting value from the product.

Self-promotion and slides

Check it out: ProductCamp Twin Cities 2024 conference presentations, from PCamptc.org

Shameless self-promotion warning. I (Jason, The Pollinator’s editor) recently delivered a presentation at ProductCamp Twin Cities, a local (Minneapolis-St. Paul, MN, USA) conference for product professionals sponsored by the local chapter of the Product Management and Development Association. The conference organizers have published the slides that accompanied all the speakers’ presentations, including mine.

My talk, Cultivate Your Garden: Adopting a Digital Product Model Even If You Don't Sell Digital Products, was targeted at companies who might not think of themselves as digital product companies. If that sounds like your cup of tea, check out my slides, available in PDF format.

Before you download the PDF, I should emphasize that Powerpoint or Keynote slides are rarely the most interesting element of a good conference presentation. After all, slides are mere props; the script and delivery are far more important than the images and bullet points that a presenter displays on the screen. Understanding a presentation by reviewing the slides is a bit like understanding Hamlet by looking at a skull and a dagger.

Still, my presentation’s slides can give you a taste of the topic and thesis. If after looking at the slides you would like to learn more about applying product models to non-product companies, let’s gab. Just email me at jason.scherschligt@solutiondesign.com. If you’re lucky, I could even force you to endure a private retelling of my ProductCamp talk.

Outside the box

Powers of Ten is a classic ten-minute film produced by the legendary Eames design studio in 1977. It starts by depicting a couple enjoying a lakeside picnic. The camera then zooms out at an exponential rate, so that every ten seconds the frame depicts another power of ten in scale. Soon we see the city (Chicago), and the earth, and the solar system, and galaxies, and the vastness of deep space. Then, just when we’re feeling cold and alone, we zoom back in to human scale, pausing briefly with our picnickers before heading the other direction, into negative exponents, getting ever more microscopic, seeing skin cells, organelles, and ultimately protons in an atom. The center of the shot never changes; only the resolution does.

I think this is a great metaphor for the work of a product manager or product team. Sometimes we need to think broadly; other times we need to work small. All the while we’re keeping the same user, problem, product, or business at the center.

Check it out at Power of Ten (YouTube).

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 jason.scherschligt@solutiondesign.com.

• 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.

The three types of friendship. "Friends of pastime, friends of advantage, and friends of the good", 15th century. Artist unknown. Public domain. Source: Wikimedia Commons. https://commons.wikimedia.org/wiki/The_three_types_of_friendship.jpg

A prominent online retailer recently posted a job opening for a position titled Product Manager: Checkout Experience. That title—that particular delineation of responsibilities—tells us a lot about how that business thinks about their digital product portfolio and their outcomes. They must realize that details of a checkout experience influence important e-commerce metrics, like cart abandonment rates, repeat visits, upsells, and ultimately online revenue. They have decided that the experience of checking out is worth managing as a product (with metrics, roadmaps, bets, goals), and therefore that it is a product.

A challenge for product management teams and leaders is simply classifying their portfolio into individual products, operated by individual product teams. As a business grows (or shifts from running IT projects to managing products), its leaders will inevitably wonder where to draw the boundaries around products.

This line-drawing is particularly tough for companies who started as something other than digital product companies, like a manufacturer, a service provider, or a museum. And many SDG customers (and therefore many of you Pollinator readers) fall into this category. These businesses aren’t darling startups; they are enterprises; they have systems that have accreted over years, even decades. And those systems are integrated both loosely and tightly, boundaries are fuzzy, even in dispute, one digital experience influences the next, data flows across them, and somewhere someone maintains a fragile spreadsheet upon which the whole ecosystem depends. None of this is neatly packaged on a shelf and sold as discrete SKUs.

And now consultants like me are advising them—are advising you!—to manage all that stuff as products?! The gall of us. No wonder you ask: ok, hotshot consultants, where do I start? I mean, what even are my products? My business offers complex financial services, not iPhone apps of cat videos. What do I assign to which product manager or product team? What’s my version of “checkout experience”?

This issue of The Pollinator features bloggers and thinkers who have advised on this fundamental task of classifying a product.

First, our own perspective:

• Acknowledge that your boundaries will not be perfect. But don’t let that prevent you from starting to draw them.

• Here at Solution Design Group, we generally default to organizing by outcome. What user behavior do you want to drive and what metrics you want to advance? How can a major metric (a North Star) be broken into reasonable input metrics? Assign a team to drive each input metric through experiences and technology and services. That’s that team’s product.

• Here’s a secret for the advanced product leaders: your products might not be parallel. Indeed, at one of the most successful product orgs I ever led, products took on different shapes. We started with a product manager and team for a major element of the total user experience, and then added a product manager for another core experience, a product manager for a type of technology interaction (mobile), and a product manager for a specialized and important type of user who interacted in all of these experiences.

• Start small, if you can. You don’t need to productize every system. Put in place a team of empowered pioneers who are charged (and funded!) to drive a meaningful outcome. Equip them with access to their users, an ability to measure something meaningful, and a clear vision. Turn them loose and learn from what they learn.

You may be thinking: any of these methods will require some serious transparency, communication, and negotiation. But of course, that’s life in product. Indeed, as a reader of The Pollinator, you’re probably already pretty good at those things.

On to the Garden,

Around the Garden

Five options depending on three variables = one great way to think about your product team’s structure

Check it out: 5 methods for organizing your product team to maximize productivity, Noa Ganot

This article has been floating around for a while, but it remains one of The Pollinator’s favorites on the topic of product team structures. Product advisor Noa Ganot, of the Israeli firm Infinify, shares her foundational advice for organizing your product team. Her five methods: using layers, using functional modules, customer personas, user journey phases, and using goals.

We appreciate that Ganot also describes the type of organizations likely to benefit from each model. For example, she explains that organizing by user journey works best for “large products, where each phase in the customer journey has enough substance to it.”

Helpfully, she rates these methods using three variables:

• Completeness

• Independence

• Balance

By analyzing these variables and their fit to your situation, you can determine a promising starting point for structuring your product portfolio and team. But as you do this, don’t forget to follow her wise advice:

Indeed.

An example of a team that’s done it

Check it out: How internal product teams drive growth at Wise, Louron Pratt, Mind the Product

In this profile from renowned British product consortium Mind the Product, we learn how a successful product company, Wise, applies product models to its internal functions. The profile, written by Mind the Product’s Louron Pratt, describes how Wise tackles challenges like regulatory issues, efficiency, and scaling. We also get a glimpse of Wise’s product org structure and culture:

Read it if you’re interested in seeing first-hand how a company can apply product thinking to internal functions that, in another era, might have been run as discrete IT projects.

Three methods for identifying your product

Check it out: How to Identify your product, Inside Product

This recent issue of a newsletter called Inside Product describes how organizations can identify their product structure. While it starts with the obvious and easy models for simple products, it gets interesting when it discusses more complex software or internal products.

The writer—and by the way, we here at Pollinator HQ wish they’d post their name!—suggests three approaches:

• By business process

• By system

• By a combination of technology and product

The first two options are pretty straightforward; the latter is a hybrid that we hadn’t seen before. In it, the teams are dedicated to technology domains, while the product managers are associated with business initiatives. Combos of teams and product managers are put together depending on priorities.

How to choose from these models? As always, it depends on whether your organization is outcome-focused, requires flexibility, or is starting its product team journey. We like how the Inside Product writer encourages experimentation and flexibility, which is valuable for teams in any stage of product development.

A perspective from an HR professional

How to Establish a Product Organizational Structure, Jen Taylor, The Org Chart

This article offers a summary of product structures from an HR and organizational development professional. It’s reminder that Human Resources departments can provide a useful point of view that we product, design, and tech leaders might overlook.

The post includes a comprehensive (although relatively shallow) explanation of product roles. Its strongest section is the summary of advantages to a business of a product-driven org structure:

We don’t love everything about the article. In particular, its opening’s emphasis on “chain of command” may be contrary to the empowered product team model that The Pollinator favors. And we wish it went deeper into the process for defining your products. Instead, it offers just two sentences that won’t be much help to product leaders seeking advice: “Outline your product lines based on factors such as market segments, product lifecycle stages, and required resources. This will help you organize new teams and allocate resources effectively.” We’d like to see more.

But as a summary that can help an organization’s leaders understand the value of organizing around products, it’s effective.

Outside the Box

One of SDG’s managing directors clued us in to Ventusky, a detailed, interactive look at atmospheric patterns and weather all over the globe, with sophisticated filters and layers. The UX is exceptional. We found it especially (and heart-breakingly) useful for tracking the recent back-to-back hurricanes that devastated homes, businesses, and lives in the southeastern US.

Check it out at https://www.ventusky.com/

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 jason.scherschligt@solutiondesign.com.

• 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.

A "Cox's" Orange Pippin apple (Malus sylvestris cv.). Coloured zincograph by J. Andrews, c. 1861, after himself. Wellcome Collection. Source: Wellcome Collection. Public domain license.

When I was a kid, I’d frequently cook up inventions. Before I had left elementary school, I had “invented,” among other things, a portable hang glider for kids; the snowboard (yes, the snowboard; this was c. 1980, and I didn’t know such a thing already existed in distant places like California or Colorado); a speech-to-type machine; a handheld foreign language translator; and boat-like shoes that would enable their wearer to walk on water.

Before you praise my precociousness and marvel at the fortune I must have made from these contraptions, I should clarify: these inventions of mine never existed in the world. They were manifested in brief descriptions and crude drawings, or sometimes even just in my boyish brain. Concerns like feasibility or even physics didn’t cross my mind—I thought the job of inventor, of innovator, was simply to apply one’s imagination to the world. If you have a child, or have ever been a child, you probably recognize this imagining instinct.

While a nine-year-old’s imagination is a mighty thing, it misses the important, relentless work of execution. That means testing how this thing might be made, learning and overcoming all the flaws in our original idea, overcoming risk, and determining how we’ll take this thing to market.

I know this is no great insight; innovators from Nikola Tesla to Steve Jobs have remarked on execution’s superior position to mere ideation. (“Ideas are worth nothing unless executed. They are just a multiplier. Execution is worth millions” -Steve Jobs) And there’s a reason that the ancient Athenians—known for living in a place populated with philosophers, playwrights, and wisdom-makers—had a soft spot for their Olympian god Hephaestus, the blacksmith, the maker, the craftsman, with his talent for the hard, humble, and noble work of executing. I like to think that Haephestus kept head-in-the-clouds guys like Aristotle and Aristophenes focused, offering a kind of feasibility-for-philosophers service.

This month’s Pollinator is dedicated to product innovation—and not just sitting on the shore imagining that we might strap little boats on our feet enabling us to stride across the lake. Innovation may start in the imagination, but it won’t last if it doesn’t leave that cozy birthplace and get out into the wide, cold world. To avoid an early expiration, the spark of ideation goes through a relentless process of identifying and then developing new ways to fulfill a durable mission, testing those ideas, refining the most promising ones, and manifesting them with that thrilling mixture of learning, effort, and teamwork that characterizes the best kind of product work.

Great Hephaestus’s ghost, this stuff is fun.

On to the Garden,

Note: The Pollinator is now on LinkedIn. While this monthly rag that you’re reading right now will continue to be SDG’s primary publication on product, we’ve just got so much that we want to share, discuss, and debate. Our LinkedIn page is where we’ll keep conversations happening all the livelong month. Please join us at https://www.linkedin.com/showcase/the-pollinator-sdg

Around the Garden

Harvard Business Review’s Middle Path to Innovation and SDG’s innovation services: a discussion with SDG’s Ryan McKesson

Check it out: The Middle Path to Innovation, Regina E. Herzlinger, Duke Rohlen, Ben Creo, and Will Kynes, Harvard Business Review

Solution Design Group Account Executive Ryan McKesson recently shared this article from Harvard Business Review on corporate innovation processes. The Pollinator chatted with Ryan to discuss this HBR article and how outside firms can help companies innovate.

The Pollinator: Ryan, what struck you about this HBR piece?

Ryan: Well, I read it on a plane. And maybe it was because I was in the air, but it helped me envision three different innovation “altitudes.” High in the stratosphere is the idea of big transformational innovation. But that type of innovation process and investment is too big and gnarly for most companies. I mean, it’s just so risky. And on the other extreme, down near the ground, there’s a kind of incrementalism that’s low risk, yeah, but also low reward. When you innovate at this lower altitude you are really just releasing standard new features. I appreciated this HBR article showing a middle path.

The Pollinator: Yeah, the HBR article calls this middle path the Growth Driver Model. The way I read it, it’s a structural model where a company uses outside partners and investors, sets up an innovation accelerator outside of its balance sheet, and then drives innovation from this parallel structure into the company itself. Am I reading it right?

Ryan: Yes, I think that’s right, but I am less interested in the financial and organizational structure than in the principles and process of that kind of model. I think companies in our market [Ed. Note: SDG tends to work with mid-sized firms in traditional industries] can adopt these principles without setting up subsidiary companies.

The Pollinator: I think I agree, but explain how that might work.

Ryan: Well, in my experience, companies like many SDG customers don’t really need help being innovative, but they may need help doing innovation. I mean, they have incredible insights, skills, and knowledge within their teams—but they may lack a framework, or tools, or even just the time.

So yeah, while this Growth Driver middle path does involve companies establishing subsidiary innovation companies with private equity investors, the real value is in setting up a parallel structure that has the capacity—actually, the mandate—to innovate and to drive that innovation into the business.

The Pollinator: Yeah, but isn’t that model available to all these businesses now? If they have the skills, why do they need investors or partners to do this with them?

Ryan: Oh, that’s my other big takeaway from the HBR article—the idea of an outside partner helping you innovate, through structure, coaching, and accountability.

I mean, I could go to the gym and work out every day. I know how to do that. But a personal trainer is someone I’m accountable to, who also has done this with others and has generated results. So I use the outside expert.

That’s why innovation services from a partner like SDG are valuable. Not because you don’t have the skills, but because we can guide you and create the structure to do something that you have the skills to do.

The Pollinator: Yeah, I like that. Innovation requires a kind of discipline or habit, and outside partners can enforce that. Is that what you see with this middle path?

Ryan: Yeah, that’s right. I mean, there’s a lot more to it, but innovating well means driving ideas to prototypes and through some kind of validation process. Then the ones that have potential move into the business for refining and operationalizing.

I don’t think of this model or these partnerships as outsourcing your innovation. Instead, especially if you have the right partner, it’s a way to insource it. By that I mean it is a way to build a bridge between all the smart innovative tech and design people in your company and the operations of the business. A good partner can help you do that, and can then empower you to keep doing it yourself.

Shameless self-promotion: Solution Design Group, the publisher of The Pollinator, offers innovation services using a structured, time-boxed model that we call Guided Innovation. Check it out at https://www.solutiondesign.com/guided-innovation

Consumer Reports: not just your father’s reviewers of refrigerators

Check it out: https://innovation.consumerreports.org, from the team at Consumer Reports

Most Americans are familiar with Consumer Reports. When I was a kid, CR was a popular print periodical that offered ratings and reviews of appliances, cars, and other consumer products. They’re where I first learned what Harvey Balls are.

With the rise of the web, Consumer Reports of course adopted an online publishing model. To this day, their reviews and ratings remain a respected, impartial source for anyone seeking advice on consumer goods.

But did you know that Consumer Reports is also a great example of an organization with a world-class digital and product innovation practice? In fact, Fast Company magazine recently named Consumer Reports one of the most innovative organizations in the world.

Check out innovation.consumerreports.org to see examples of the innovation initiatives that Consumer Reports is working on. All of these disparate efforts are rooted in CR’s mission to empower and inform consumers. Examples include a kind of “nutrition label” for cybersecurity and a dark patterns tip line enabling consumers to report websites using design practices that deceive their customers.

Consumer Reports Innovation Website

I love how they use this website to innovate in public. You can see initiatives in various stages, from research to prototype to launch. They also openly collect ideas and insights from the public. It’s a great, even inspiring, example of an organization innovating with contemporary technology to fulfill a mission it has had since its inception.

We love encountering venerable organizations that are relentlessly remaking themselves through thoughtful innovation. Kudos to Consumer Reports for this good work.

Operators and innovators, unite: Reconciling two necessary product functions

Check it out: Can Product Operations and Innovation be Friends? Greg Bayer, Silver Ridge Advisors, for Mind the Product.

One of the enduring conflicts, and perhaps enduring myths, of product work is that innovation and execution are inherently opposed to one another. And I suppose there is something to this. The mindset and models for innovation require rapid ideation, deep comfort with ambiguity, and a willingness to throw it all away. Product operations, on the other hand, is concerned with reliability, certainty, and scalability. And while I believe we humans are infinitely complex beasts, capable of operating perfectly well in seemingly contradictory contexts, I can see why these impulses might create some tension.

So what’s a product team to do?

This piece from consultant Greg Bayer, written for Mind the Product, offers some good advice for reconciling product operations and product innovation. His tips include:

• Build a habit of rapid testing. Product operations might facilitate the experiment design, freeing product innovators and designers to innovate based on the insights garnered.

• Prioritize effectively. Instead of just creating to-do lists, connect product work to meaningful team, business, and market goals, using techniques like OKRs.

• Set up a good cadence of connections. Bayer outlines different touchpoints for innovators, operators, and others, including Monthly Product Reviews, Monthly Broadcasts, and Quarterly business reviews.

Innovators and operators alike will appreciate Bayer’s advice. They might even read it together.

Pollinator seedlings: a miscellany of additional insights for product professionals

What is Product Management’s Role in Promoting Innovation? - ProductPlan
This brief post from product management software platform ProductPlan is jam-packed with practical, actionable advice for product managers seeking to extend innovation beyond their immediate teams. Our favorite nugget? “Encourage ideas from across the company—and make sharing them fun.”

Innovation is just good Product Management - Adrienne Tan, Brainmates
This is a well-written post from Arienne Tan of the Australian product management consultancy Brainmates. It’s one part advice, and two parts well argued opinion. Her thesis: “The essential purpose of product management is to execute the principles of innovation.” She makes a strong case.

The Open Innovation Barometer (Whitepaper. .PDF format) - The Economist
Open Innovation (OI) is an approach to innovation that emphasizes working outside of your company’s walls. Common OI practices include joining consortia of similar firms, developing university research partnerships, hosting ideation and start-up competitions, and co-creating with customers. Economist Impact researched global open innovation practices by surveying 500 leaders across industries; this report is the result.

When innovation goes south: the tech that never quite worked out - Diana Gitig, Ars Technica
This is an eye-opening summary and review of a recent book, Invention and Innovation: A Brief History of Hype and Failure, by Vaclav Smil. Through the review and profile, we get a look at innovation’s graveyard: technology innovations that failed, for various reasons. Some failures had unforeseen awful consequences (the pesticide DDT); some never lived up to the hype (supersonic commercial jets). Innovators will enjoy the summary, and might even pick up the book itself.

5 reasons to work with the competition, according to business leaders - Mark Samuels, ZDnet
One novel way to innovate? Partner with your competition. This article asks business leaders from well-known companies to explain the value of innovating in collaboration with your competitors. A good example: building common data models and standards from which you and your fiercest rival both might benefit.

Outside the Box

As autumn comes to the American North, this product strategist’s tastebuds turn towards apples. The Apple Rankings website is a passion project from a chap named Brian Frange. It’s a remarkably comprehensive resource on this most archetypical of hand fruits. By day, Frange is a comedian and a writer, and it shows in his language, as in this excerpt from a review of an apple called Lady Alice: “Alice is a perfectly nice lady, but like an office colleague who sits somewhere over there, you will forget this apple’s name in the elevator even though it may have joined you for lunch on multiple occasions.”

As a Minnesotan, I was pleased to see that the many of the top apples in the Apple Rankings list were developed at the University of Minnesota. I’m munching on a Minnesota-grown Honeycrisp (Frange’s number 2 ranked apple) even as I type this.

Grab an apple and check it out at https://applerankings.com/

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 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 jason.scherschligt@solutiondesign.com.

• 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.