Edward Hopper, “Soir Bleu” (“Blue Evening”). 1914. Whitney Museum of Art. Public domain.

I enjoy so many parts of digital product and UX work. I like being surrounded by talented people practicing their crafts at an expert level. I like that the job requires top-grade rhetorical skills and top-grade analytical skills. I like meeting interesting people doing things I hadn’t imagined, seeing their work and lives, and discovering how I might help them through technology, experiences, and services.

Mostly, I like that a product is how a group of people (a business, a non-profit) puts its talents together to solve a problem for another group of people (its customers or users). In short: I like working with people to improve the experience of other people.

Astute observers of tech and culture say that humanity has just stepped out of the starting blocks of a grand technical and social race that might change society forever: the rise of Artificial Intelligence. This moment in history is already being called the dawn of a new age, or an era. That’s a mighty declaration. Ages and eras are history’s big blocks.

I came across a great description of this type of transformative tech from an MIT researcher named Justin Reich. Reich says Artificial Intelligence is an arrival technology, not an adoption technology. AI is here, whether individuals want to adopt it or not. An analogue: the introduction of the electrical power grid in the late nineteenth century. It too arrived suddenly, changing economics, business, domestic life, communications, and labor. It was both potent and dangerous. It made life easier and more complicated. It required both breathtaking innovation and reasonable regulation. It was also inescapable; only a minuscule fraction of humans never encounter electric power.

Smart product professionals are thinking the same way about AI. It’s changing how we ideate, prototype, plan, document, test, measure, and deliver products.

But while AI is transforming the way product teams work, I’m hopeful that the heart of our profession will still be people. Pesky human beings—curious apes with social systems and inner lives and job descriptions and credit scores—should always occupy a prominent place in our product ecosystems. Sure, we can build agents and we can prompt-conjure code, imagery, and even language. But if we’re doing our job well, the agents and the prompts are all, at some point, for the benefit of some person, made of flesh and blood and soul and mind.

So when you, Pollinator community, contemplate how AI should affect your product practices, I urge you to focus on the people. What human problem are you solving? Are you making some fellow person smarter, healthier, safer, or happier? Something I love about working with SDG is that our AI, data, and machine learning consultants never forget the humans.

Yes, Artificial Intelligence has arrived. But human intelligence was already here. May it never leave.

On to the Garden,

Around the Garden

So what do you actually do around here?

Check it out: I interviewed 100+ AI Product Managers. Here’s what they actually do, by Aakash Gupta

This must have been an ambitious undertaking. Product consultant Aakash Gupta interviewed over one hundred product managers who are building AI-enabled features. I appreciate how he focused on foundational questions:

• What do you actually do?

• What knowledge do you need?

• What skills matter?

• What tools do you use?

This article is his analysis of the responses. Key insights include “The best AI PMs I interviewed spend 30–40% of their time on discovery” and “Multiple AI PMs told me the same thing: ‘The hardest part is telling stakeholders no when they want to use AI for something it’s not good at’.”

If you’re working on incorporating AI capabilities into your product and your practice, bookmark Gupta’s article.

Everybody’s talkin’ at me

Check it out: They Asked About AI Tools. Almost Nobody Asked About the Business, by Irina Bulygina

Irina Bulygina is a Madrid-based product manager who comes to product and entrepreneurship from a long career in marketing and business development. Here she reflects on her experience building a new business in the AI era. Many colleagues asked her about the tech she used, the AI model she chose, the way she built features using AI and other technology.

But to Bulygina, the more important questions were fundamentals of her business. And, she laments, the curious advisors, so interested in technology and tools, rarely even asked her about customers, markets, and problems worth solving. She diagnoses it as people confusing an application with a business.

Product folks should remember Bulygina’s lesson. We are deeply engaged in the technical details of a product, but that product serves our business by satisfying a user or customer. So if you find yourself describing your application, also explain the problem you are solving, your competitive differentiation, and your economic thesis. Those are where your real opportunity lies.

When I fight authority

Check it out: Renegotiating done is the closest thing to authority most product managers actually have, by Jeff Gothelf

This is a useful, pragmatic piece from the consistently wise Jeff Gothelf. Gothelf describes the cold reality faced by product managers and product teams who want to "focus on outcomes, not output," but whose context might have dates and deliverables (that is, "outputs") assigned in a way that the individual Product Manager can't really change.

That’s a very real question. His answer? Product managers faced with that challenge should negotiate and document a definition of done that includes an outcome connected to the assigned output.

Great stuff.

More blossoms

• From Project to Product — New Learnings for Enterprises — Part 1. Saeed Khan thoroughly outlines the differences between product- and project-driven models. Once you finish part 1, move on to Part 2.

• AI polish makes it harder to spot problems, but there’s a quick fix. The folks at Atlassian explore an unintended effect of high-polish inherent in AI-generated prototypes, design artifacts, or interface copy: the gloss can hide problems in the design or functionality.

• What Actually Happens When Sales Overrides Your Roadmap Over on LinkedIn, Stephanie Leue examines a situation that product managers and teams know well: sales teams selling something that isn’t on your product roadmap, or adding something unexpected to your roadmap to win an important customer’s business.

• Making Sense of the New Product Development Model. Rich Holmes from Department of Product uses a well-known consumer product and company, Spotify, to explore how AI is changing product thinking and product development. The diagram at its heart is the best part.

Outside the Box

Like many of my fellow SDGers, I’m nerdy in myriad ways. One way is that I dig vexillology, the study of flags and heraldry. Flagpedia is a fun site for those who share this particular brand of dorkiness. It features directories of flags of countries, US states, and international organizations. There’s a quiz where you can test your skill at matching flags to countries. It also includes technically well-made vexilloligical utilities like catalogs of flag emoji, Unicode characters for each emoji, and downloadable flag images in icon, bitmap, and vector formats. My only wish: that it included interesting city flags, like the flags of Glasgow, Scotland or St. Louis, Missouri.

Check it out at https://flagpedia.net.

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

Eugène Delacroix, Michelangelo in his Studio (detail), French, 1849-50. Oil on canvas. Public domain.

At the boyish age of 87, Michelangelo, the famed Renaissance artist, is said to have declared, “Ancora imparo!” Translation: “I am still learning!”

The story may be apocryphal, but I love imagining octogenarian Michelangelo’s unbounded joy in learning. He discovered something new and reveled in the fact of that discovery. In two Italian words—”Ancora imparo!”—we see what animates one of history’s great geniuses: new learning, over a long life.

We moderns could learn a thing or two from old Mike from Florence. Michelangelo’s insistence on unceasing learning throughout a career is especially important for those of us working in digital products. Novelty bombards us, and it can be hard for a well-meaning product pro to keep up. Try this tool. Prompt like this. This framework is hot; stop using that old, cold one.

Once we’ve reached a certain level of experience, it’s easy to respond to the novelty with, “Hey, settle down. I’ve been working on this stuff for a while. I know how this works. I don’t need your new-fangled systems.” But the risk of such an attitude is stagnation. Michelangelo would have hated that.

If you had to pick one characteristic that distinguishes a great product practitioner, you could do worse than choose straight-up, unadulterated curiosity. So I say Be like Mike. Never stop learning. Ask a ton of questions, and keep questioning the answers. Why do people in our market struggle with this problem? How could we generate value if we solved it for our users? Oh wow. That’s how it works? I am still learning!

Here’s a back-to-school season challenge for all of us. Think of something related to your professional life that you would like to understand better. Then, create a plan to help you learn it. If that sounds overwhelming, enlist the help of an artificial intelligence tool. For example, try feeding your favorite LLM a prompt like this:

Give it a try, and then commit to the learning. You might experience a rebirth—you know, a renaissance.

On to the Garden,

Around the Garden

A Product Expert’s AI Odyssey

Check it out: The Call to Adventure, Teresa Torres (Video + Illustrated Transcript)

In this recent talk, well-known product writer and speaker Teresa Torres (known for Continuous Discovery Habits and the Opportunity-Solution Tree) chronicles her 15-month journey to build her AI skills and incorporate AI in her product coaching work. Pollinator readers will appreciate her humility and her storytelling.

The tale begins when Torres broke her leg in March 2025. While out of commission, she identified an opportunity to augment her expertise (product discovery) with AI capabilities. She underwent a crash course in engineering principles and tools, using Claude as a guide. Over the next year, Torres ended up building new products and rethinking her entire business and service offering to take advantage of what she’d learned. It’s a rip-roaring tale. If you have thirty minutes, watch the video. Otherwise, the illustrated transcript is a quick read.

I've been on my own journey to discover how to adapt my thinking and practices using AI, while preserving the things that are important for humans to retain. It was helpful for me to hear a respected and experienced product expert like Teresa Torres describe her own journey (which is still very much in process). I think you’ll appreciate it, too.

Financial Acumen

Check it out: Owning the Financials: The Future of Product Management?, by Corinna Stukan, InsightsDriven

While contemporary product managers tend to be skilled at discovery, prioritizing, prototyping, and communicating, their financial acumen often lags in comparison. Corinna Stukan aims to fix that. She writes a newsletter called InsightsDriven on business insights for product professionals. In this issue, she helps product managers become more financially astute. In fact, business financial literacy might be the single most important thing that a product manager can learn.

Stukan is an entrepreneur and an executive. She has made tough financial decisions and knows her way around a balance sheet. I appreciate how she frames product financials as a learning opportunity, and supports that with actionable steps that any product manager can understand and apply. Her key steps:

1. Get crystal clear on your business

2. Do a side project

3. Lose the mental blocks

Finally, Stukan connects the financial advice she offers with Product Management’s history, dating back to the famed Procter & Gamble “brand man” concept. She sees a future where product management is anchored in business, not just tech. After all, technology trends come and go. But delivering financial results never goes out of style.

From Parts Unknown

Check it out: Mapping the Unknown — The 10 Steps to Map Any Industry, by Steve Blank, on Medium

One of the wilder things about being a consultant on digital product topics is exposure to industries and problems that I’d never even considered. Topics I’ve learned about as a consultant at SDG include methane emissions in the global oil & gas industry, training for HVAC technicians, logistics for transporting road salt, and drones that monitor the health of crops. Each of these domains is populated by companies, vocabulary, history, regulations, and lore—and it’s all worth knowing.

Product professionals are often well-schooled in technology, prioritization frameworks, and communication methods, but woefully on their own when it comes to learning how their product’s industry actually operates. This brief, delightful article from entrepreneurship and product legend Steve Blank helps us overcome this gap. Blank’s article is a few years old (2022), but it’s one of the clearest explanations I've seen for understanding the structure of an industry.

Blank’s process is iterative and additive, much like his famed lean methods for prototyping and MVP-making. Think of it as “lean industry immersion.” I like how his process unfolds through drafting and iteration: to me, this is essentially a writerly approach. He advises starting with quick lists of companies you know about, then building connections to indicate relationships, then adding details as your research uncovers more of the landscape.

Whatever industry opportunity comes my way next (Beekeeping? Soup-making?), I’ll use Blank’s process to comprehend it.

O Captain! My Captain!

Check it out: Captain, Coach, and Counselor: The Multifaceted Role of a Product Design Lead, by Robyn Johnson, on Medium. Recommended by SDG’s Allison Lorenzo.

SDG colleague Allison Lorenzo is a skilled and sensitive UX designer, analyst, and collaborator. So when Allison recommended this post from Robyn Johnson, I had to check it out. Johnson, a product design lead at IBM, uses her own experience to explain how a product design lead—her job—needs to deftly bounce across three different roles: captain, coach, and counselor. Here’s SDGer Allison describing why this matters:

More blossoms

• The Future of the Website. If you feel like our beloved World Wide Web has lost its way, this article might soothe your soul. Here entrepreneur and web standards expert Joost de Valk describes how the web of the future will simultaneously serve human and agentic users, and how a technically perfect, standards-based system is now totally possible, and preferable. Lovely.

• Intentionally Human: Product Managers in the AI Era. Jeremy Daly is the kind of product leader the Pollinator loves: he sees product work as fundamentally a human endeavor. In this post he examines AI’s effects on product management through a series of “from-to” shifts, including From PRDs to Prototypes, From Feedback to Fluidity, and From Ideas to Instant Iteration. My favorite is probably From Operators to Orchestrators.

• Too Good With People. Product managers need to communicate, collaborate, and influence in every direction: in, out, and up. The ability to interact with all types of people is often described as a product manager’s superpower. But here product consultant Noa Ganot argues that skill in interacting with people can actually doom a product manager’s success. She summarizes this in a pithy subheading: “They didn’t hire you to agree.”

• The AI Competence / Judgment Gap. One of our favorite product writers, Itamar Gilad, tackles one of our favorite topics, wisdom and judgment in product management. The coolest insight is his description of a “danger zone” in AI-enabled product: “With AI, your proficiency level in doing exceeds your proficiency level in judging. In other words, AI lets you do work that you’re poorly equipped to judge. A PM may generate bad production code and a developer may choose bad ideas, and neither can tell the difference.”

Outside the Box

iFixit describes itself as “a global repair community of people helping each other fix their stuff.” The most prominent feature of the site is a vast directory of diagrams and manuals for all manner of devices, machines, and doodads. If you need to fix, say, a broken spring-loaded tape measure, iFixit will have the manual that shows you exactly what’s happening inside the mechanism. There’s also an engaged community of advocates for repairability, guided by the slogan “the future is repairable.”

Check it out at https://ifixit.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.

George Stubbs, Haymakers (detail), English, 1785. Oil on canvas. The Tate Gallery. Public domain.

For a good time on a Saturday night, look at the career path of product managers, product directors, heads of product, and the like. Seriously: just fire up LinkedIn or the “writer profile” blurb of a product blog or discussion, find someone in a product leadership job, and look back through their career paths or even their pre-career training and education.

Here’s what you’ll notice: very few started in some kind of entry-level or junior product management job. Indeed, while some big tech firms, like Google or Meta, have formal associate product management career pathways, for many companies, an entry-level product manager is an oxymoron, like an entry-level CFO would be.

Instead, you will see coding backgrounds, data science backgrounds, marketing backgrounds, finance backgrounds, and design backgrounds. Software developers, business analysts, customer service professionals, and UX designers all make excellent product managers. Personally, I started my technical and business career doing software documentation, web content management, information design, and even some journalism. When I entered the workforce as a greenhorn technical writer, I didn’t know what a product manager was. I will even confess that when I got my first product manager job, twenty-six years ago, I wasn’t totally sure what a product manager was!

When people who are early in their careers ask me what path to take to become a product manager, I advise they start by participating as a member of an effective cross-functional product team, using whatever skills and job role you have now. You might be a developer, a copywriter, a designer, a project manager, a financial analyst. But when you find yourself on a product team, use your skills to help that team make better decisions about value, priorities, vision, and user needs. Contribute both through and beyond your named role. Do that enough, and you’ll have the opportunity to lead some decision-making about the product. That’s probably the surest path to a product career.

No, it’s not linear. Product is a job you probably come to sideways.

But at bottom, the skills are durable. Communicate well. Write well. Observe users with empathy and respect. Help people succeed. Collaborate effectively. Simplify the complex, and challenge the apparently simple. Contribute to better investment decisions.

In this issue of the Pollinator, we feature recent writing from people with different backgrounds, all of whom are now leading product teams or product thinking. I have included brief notes about their paths. It just took a little research. Yeah, I did it on a Saturday night.

On to the Garden,

Around the Garden

Escape velocity

Check it out: PM Escaped the Product Team, by Falk Gottlob, on falkster.com

Falk Gottlob’s early career in product: software engineer track at Microsoft

Entrepreneur and technologist Falk Gottlob articulates something important for product managers to understand: the traditional duties held by a product manager are, in many organizations and industries, “escaping” the product management job function. The cause, of course, is the power of AI and agentic development. As Gottleib puts it:

Maybe I’m just a hopeless optimist, but I see this escape as an opportunity for seasoned product folks like the Pollinator’s readers. If, say, the financial analyst or corporate lawyer now is trying to tackle product challenges, surely our skills and experience are even more useful to our companies. Step one: schedule a lunch with that financial analyst and corporate lawyer.

R-E-S-P-E-C-T

Check it out: Empathy and Delight Mean Nothing When the Software is Disrespectful, by Pavel Samsonov, product designer and manager

Pavel Samsonov’s early career in product: graphic design, HCI, UX design, product design

Oh, this article hit close to home. “Empathy” and “delight” are among the product and UX buzzwords I’ve thrown around often in my product work. Pavel Samsonov, a consistently excellent writer and thinker on design and product, has me rethinking this. He explains that these terms mean nothing when we don’t respect our users. Without respect, empathy becomes pity.

One of the more provocative ideas here is that friction—which product makers have often tried to eliminate—may in fact have value in a digital product experience.

So before (and after!) empathizing with a user, respect them. Don’t infantilize. Don’t overwhelm them with AI-generated stuff you didn’t carefully edit and condense (or write yourself in the first place). Show your users care.

I’ll remember this one.

Loop-de-loop

Check it out: How I AI: Designing Agent Loops in Claude and Codex, by Claire Vo, ChatPRD

Claire Vo’s early career in product: interactive design, social media, marketing, branding

Recently, I’ve been engaged in conversations and even experiments at SDG about loop-based techniques for product management and product development. Maybe it’s the Baader-Meinhof phenomenon, or maybe loop-based AI techniques really are having a moment. Either way, I've been seeing them everywhere.

This post from Claire Vo explains loop techniques in a product manager’s language. Vo is the founder of ChatPRD, a popular SaaS product for product managers. She knows both AI and Product well. Her post includes a Youtube video where she describes using loops in great depth. It’s a thoughtful, well-sourced examination of a technique we’ll all be hearing more about.

More blossoms

• Skill Issue: How We Built an OS for PMs at Figma. A YouTube video from the team at Figma about their internal product management AI stack, which they call PM OS. (To be clear: here, as in just about anything we mention at the Pollinator, “PM” stands for “Product Manager,” not “Project Manager.”)

• What Watching People Taught Me About Product Development. A Product Coalition post by Ruairi McGuinness on the value of spending time with your users, in their environments. “When I see an unexplained variation in the data, I now resist creating an explanation from the dashboard alone. I go to the environment where the behaviour is happening, watch how people interact with the product and speak to those closest to the work.”

• Who Made This? Allie Paschal explores the notion of creative provenance, disclosure, and transparency when AI is increasingly involved in creation. “…the more a piece of work is tied to human expression, authorship, and originality, the more the audience tends to care about how it was made.”

• The Three Ps That Shaped Me: Product, Project, and Poet. Beatrice Aderayo Adekanye describes how poetry shapes her business and tech work, and vice-versa.

• The Skills That Actually Matter in the Age of AI. Graham Mann outlines 6 skills that mattered before, during, and (probably) after this Artifical Intelligence-dominated moment. “When everything accelerates, the instinct is to chase the acceleration. Learn the new framework. Master the new tool…The counterintuitive move is to master the skills that sit above the acceleration: learning quickly, adapting to change, forming real relationships, exercising judgment under uncertainty. These aren't "old skills" you're retreating to. They're the stable platform that lets you navigate whatever comes next.”

Outside the Box

Floor 796 reminds me of a compelling jigsaw puzzle illustration, or maybe a children’s book. It’s a vast interactive animation that is filled with little scenes and characters from pop culture. The organizing idea is that it’s this big floor of a giant space station, divided into rooms where crazy stuff is happening. Look for the members of KISS making burritos, or Robocop and Krusty the Clown entertaining the Rugrats poolside. Click on each character for more info and links. The creator adds to it regularly. That’s seriously a labor of love.

Check it out at https://floor796.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.

Diego Velázquez, The Surrender of Breda (detail). 1634–35, oil on canvas. Museo del Prado, Madrid, Spain. Public domain.

Product people are generators, by profession and perhaps by personality. If you have made a career of working in product, you probably aren’t intimidated by the empty canvas, the blank page, the unsolved user and business problem. You see them as opportunities to make something. So you scribble a start; you doodle an idea; you ideate, prototype, and refine.

When I write a Pollinator essay each month, I start in chaos. I’m sure I’m not alone in this. I think about things I’ve read, observations I’ve made, or problems I’ve encountered. Then I hammer out half-notes and random blurts, riddled with missteps and dead ends. For example, this essay you’re reading started with the truly dumb idea that I affirm my existence by writing sentences, but my dog is a terrible writer, and he exists, so perhaps my affirmation through writing is foolish. I quickly deleted it; it made little sense.

In the early stages of making, we rip through ideas quickly. “My dog is a terrible writer.” No, that’s silly. “Making things like sentences is an act of thinking.” That’s better, but too broad. “Product people are generators.” That might be promising; follow it. That’s how generative work (like product management or essay writing) often happens: start broad, test and reject, get narrower, then follow a line of thinking, armed with language and logic. Write it out. Test it. Write it again. See how a user or reader responds. Make it better. Follow it. Chase it. Snare it, probably with words.

That messy process of generating, testing, rejecting, and refining ideas may be more important than we realize. Which brings me to a new concept I've been thinking about: cognitive surrender. The concept was recently studied by Wharton School researchers Steven D Shaw and Gideon Nave. It’s the notion that we humans, working with AI, might be predisposed to simply accept what the AI tells us, even if its output is shallow or illogical.

I know I’ve experienced the temptation to just receive what an LLM gives me—or, worse, to copy an LLM’s output and paste it as if it were my own. After all, an AI-prompt session can be an efficient and even delightful way to work through a business, technical, or personal predicament. But I wonder: if we succumb to the LLM’s soothing syntax, are we dodging the necessary, hard work of fighting through challenges of logic and voice while maintaining sovereign decision-making? The struggle against surrender is how we get to understanding and mastery.

Make no mistake: of course I use AI-based tools quite a bit. To ignore them would be malpractice for someone in my role. But I think it’s critical that product people resist the allure of easy cognitive surrender. I try to enforce the proper relationship between my mind and the LLM. The LLM is there to suggest and assist, not to generate and perform. I think of it this way: I want the LLM to speak to me, but I almost never want it to speak as me. 

A lot of product and technical professionals begin tackling a problem with an AI session. And for some challenges, maybe that’s the best way to get out of the starting blocks. But for other problems, the best beginning is to stub out a clumsy draft, away from the AI, with the pen firmly in your own hand. If you confront the blank page yourself, alone, you’ll know the thinking was yours before the machine ever encountered it. So write a word. Make a mark. Trust yourself. Never surrender. 

On to the Garden,

Welcome, OSN Subscribers

At the end of May, I had the pleasure of speaking at a Twin Cities technology and innovation conference, Open Source North. I invited attendees to subscribe to this newsletter and join our Pollinator garden. SDG and Sweet Harvest Foods even offered a container of honey for anyone who subscribed that day.

Maybe it was my boyish charm, maybe it was my earth-shattering content, and probably it was the free honey, but that day was the Pollinator’s single biggest subscription day ever. It also made May 2026 our biggest single subscription month ever. So thank you to all who subscribed that day or that month. We’re glad you’re here. Feel free to share this newsletter with others in your networks. And I’d love to learn what you hope to get from this newsletter or to hear your impressions of it. Feel free to shoot me an email (jason.scherschligt@solutiondesign.com) or even to leave a comment below.

Around the Garden

Don’t give up the fight

Check it out: Giving up your thinking to AI, by Jeff Gothelf

Once again we recommend a post from Jeff Gothelf, a popular product and UX consultant and advisor. Here Gothelf addresses the notion of cognitive surrender without ever using the term. He advises a rigorous discipline of pushing back against an AI's recommendations, lest we fall victim to something called "intellectual leveling"—which is quite similar to the cognitive surrender notion. Gothelf borrows this concept from the neuroscientist Sarah Baldeo, who has studied how human cognition changes when we’re engaging with AI.

Here’s Gothelf describing the concept and referring to Baldeo’s work:

Gothelf has a practical suggestion: start writing (or other generative work) outside an AI, noting what you want to express before you fire up a chat session. I'd write much more than the 3-4 bullet points he recommends. I also like the suggestion from Dr. Baldeo, via Gothelf, to take intentional breaks from using AI in your writing, lest you become numb to its flattening effects. For example, if you’ve gotten in the habit of always using AI when you write, commit to writing entirely on your own at least one day each week. And that day might as well be today.

The longest hour

Check it out: The work that doesn’t get faster, by Noa Ganot, product coach, Infinify

Product pros are pressured to use AI to compress nearly every product task. In this post, Israeli product advisor Noa Ganot offers a useful corrective, noting that some essential product work resists this compression by its very nature. Discovery conversations, trust-building with stakeholders, learning a messy domain, and even just thinking hard about a problem can’t be sped up. The hour it takes to truly listen to a user is still an hour. Ganot's point is more structural than nostalgic. Speed offered by new tools is real and often welcome, but it applies unevenly. The work that can't be hurried is often the work that matters most.

Ganot recognizes the risk of mistaking velocity for progress: we might just fill the time freed up by AI with more fast work, crowding out the slow. The smarter play: use that reclaimed time to go deeper where depth is needed. For product people, that means more time with users, more presence with partners, more time “holding the initiative end to end.”

Compound interest

Check it out: Cognitive Surrender. Addy Osmani, engineering leader, former director at Google Cloud AI

Addy Osmani is a serious technologist and engineer who has worked extensively on Chrome and Gemini for Google. In this post he offers a cogent summary of cognitive surrender and similar human/machine relationships. He notes how developers surrendering to an AI’s output can produce structural weaknesses that later damage a codebase or a product. I like his use of “a tiny loan” as a metaphor, much like technical debt.

This post is squarely aimed at engineers, but strategists, designers, and product managers will find Osmani’s tips useful, too. I especially appreciated his techniques for resisting cognitive surrender. They include "introduce friction by design" and "solo time at the keyboard." (The latter is very similar to Gothelf and Baldeo's "spend time every week writing without AI" advice.)

More blossoms

• A tidy Instagram Reel from Avery Swartz summarizing Cognitive Surrender vs. Cognitive Offloading.

• Tech Policy Press article from Harvard student Evan Liu on how students are at risk of using AI tools to surrender their own thinking and learning.

• Amoeboids list of AI prompts for product managers. Pollinator readers will appreciate using them, as long as you maintain your generative autonomy.

• YouTube video of Lenny Rachitsky’s podcast episode with innovator Tony Fadell on building taste—and avoiding cognitive surrender!—in product development.

Outside the Box

Most (though not all) Pollinator subscribers are Americans. As our nation approaches the 250th anniversary of the signing of the Declaration of Independence, American Pollinators might appreciate this well-designed interactive examination of that foundational document. It’s provided by the Gilder Lehrman Institute of American History.

While it’s designed for schools and other educational uses, anyone will enjoy the quizzes and interactive games. My favorite feature: the “founder personality” quiz. It uses your responses to various scenarios and questions to match you with some Declaration-era American figure, from First Lady Abigail Adams to poet Phillis Wheatley. Apparently I’m most like Thomas Jefferson.

Check it out at https://www.gilderlehrman.org/declaration-independence/

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.

“An Artistic Gift,” Pietro Bouvier, c.1888. Private collection, Milan, Italy. Public domain, via Wikimedia Commons.

Cross-functional product teams have a remarkable new shortcut: AI-enabled tools and processes. With the right prompts in the right sequence, we can conjure something that looks and behaves like a finished product. The journey from prototype to product that used to consume months of careful engineering is now an afternoon jaunt. Who could blame a team for racing ahead?

But in the rush to generate big things quickly, we risk skipping the small things entirely. And the small things are where the learning lives.

Remember the quaint notion of a Minimum Viable Product, or MVP? With AI at their disposal, some product teams are at risk of ignoring the MVP. Why start with minimum, when maximum is so easy?

But the purpose of starting with an MVP isn’t (never was!) to deliver the first release on a path to certainty. No, the purpose is the viable part: to figure out what we can test, what we can learn, how we can put something into the hands of a user and watch what happens when they encounter it. Our first gifts to our users shouldn’t be big; big may overwhelm them. Instead, they should be human-sized, specific, intentionally narrow to provoke a response. That’s why minimum matters.

So yes, move fast, think big, but don’t forget the small. In the haze of a prompt-session, we’re tempted—who wouldn’t be?—to immediately add the next thing, and the thing after that. Smart teams enforce a discipline of stopping at low fidelity, even when they don't need to. Use grayscales and rough edges. Keep some screens blank. Focus on exploring a small, specific hypothesis. Through the interface, remind the user that this is a true test artifact, intended to teach us while they explore it. Ask them, with genuine curiosity: Would this help you? Does this make sense? How would it help you more? How would it make more sense?

Some teams, including our teams here at SDG, are already doing something interesting: pulling users into the prompting process they’re using for prototyping. Call it proto-prompting. If you’re prototyping through prompting, include the user in the process. Sit with them. Give them time to react, to misunderstand, to frustrate you, to surprise you. There, the user’s language and reactions will shape the product in real time. The AI still moves fast, but the human is still in the center of the loop, and the scale is right for both.

AI is extraordinary at shaping and scaling a product for delivery. But humans—your users are humans, aren’t they?—are the ones who teach you whether a product is worth delivering at all.

On to the Garden,

Around the Garden

All aboard

Check it out: AI Can Make Software Now. That Changes Everything. Podcast with Paul Ford (Aboard, etc.)

I’m a sucker for anything from the great Paul Ford, formerly of Postlight, now of Aboard, an AI-product development firm. In this wide-ranging conversation on the Channels podcast, hosted by Peter Kafka, Ford demonstrates a mature and honest understanding of how AI might affect custom enterprise software.

I appreciate Ford’s humility. He doesn't make wild pronouncements. He speaks (and writes) like a thoughtful person. He recognizes that we get to good by building up. So much dialogue and conversation in these wild times tends toward broad statements of what is wrong, what is right, what no one notices, what everyone misses. I resist that mode of writing; others must like it, because they sure seem to use it a lot.

Ford is a professional technologist with experience as a professional writer, and he neatly integrates the two endeavors. I love what he says about human writing having jagged edges, and the same thing applying to code. Several times he talks about "software-shaped problems" or "product-shaped problems." I hadn’t thought about that framing for the work we do at SDG (or that you Pollinator readers do on your own products), but I like it.

Wait: we’re influencers?

Check it out: The Future Is Not Yet Invented: The Product Leader’s Influence on the World We All Will Live in. Petra Wille, product coach

German product management guru Petra Wille reflects on the duties and responsibilities of being a wise leader in the face of volatility about how AI will change our future. I think she has exactly the right blend of curiosity about possibilities and healthy skepticism about economic incentives and perceived inevitability.

My favorite part of her essay: the questions she poses. For example, a Pollinator could spend a life musing about questions like “Is all of this perceived volatility and uncertainty actually distracting us from some real underlying problems we’d be better off solving?” or “Who actually gains from the current mood in the software industry?,” both of which she raises—though doesn’t directly answer—in her essay.

The core of her argument is that software will have an outsized influence on the future, and product leaders have an outsized influence on what software does, so therefore the “chain of responsibility” for the future of the world runs straight at product leaders.

Responsibility for the future of the world is intimidating, sure. But we product folk aren’t ones to shirk responsibility. So I say bring it on.

Taste test

Check it out: Why taste won’t save product managers from AI. Jeff Gothelf, Continuous Learning

If you’ve read much product content, you’ve probably seen “taste” declared as the product manager’s superpower, especially given the speed with which AI tools can crank out product. “Ah,” this thinking goes, “we shall overcome the risk of slop through our superior discernment.” I don’t even disagree with this: our taste, our standards, and our judgment are important qualities for a product manager to cultivate.

But product and UX guru Jeff Gothelf offers a contrary opinion—and contrary opinions are often worth listening to. Gothelf frames his argument by recounting an ongoing discussion with his collaborator Josh Seiden.

I love his diagnosis of the “mysterious professional fog” of soft language. His broader point: what we call taste in product work is the result of serious, disciplined craft and an outcome of hard-won learning and experience. It should be valued, trained, and, yes, funded. Don’t dismiss it as a fortuitous accident or a little genetic quirk.

Outside the Box

One of my favorite subgenres of rhetoric is the college graduation speech. Every spring, right around this time of year, we’re treated to a handful of new entrants, but only a few rise to the level of classics. The Best Commencement Speeches, Ever website from NPR catalogs the best of them—though it ends at 2015. It includes speeches from lauded writers, world leaders, and accomplished artists and scientists. One of my favorites comes from Bill Watterson, the writer and illustrator of the comic strip Calvin & Hobbes, at Kenyon College in 1989. Thirty-seven years later, these words still ring true.

Check out the whole collection at https://apps.npr.org/commencement/.

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.

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