Paradise City

I think a lot — too much, really — about the metaphoric language we use for making software products.

I know you might be groaning, and you probably don’t read The Pollinator for lessons in linguistics. But hear me out. Surely Pollinator readers understand that language carries meaning. Design, build, done, manage, code, web, interface — these are words encrusted with assumptions and history. Digital comes from counting discretely on our fingers. Prototype’s source is Greek, meaning something like “first form.” Software is a kind of neologistic wordplay, based on the much older word hardware.

Often we tech product makers choose language that’s rooted in the apparent rigor of manufacturing processes. I’m talking about words like backlog, production environment, maintenance, shipping, and handoff, which all evoke linear, controllable, assembly-line-like work.

And that’s fine, to a point. But there may be better ways of thinking about and describing our product work. This was on my mind as I observed the recent 2024 summer Olympics. The remarkable performances of the athletes were made even more glorious by the setting of the host city, Paris. Here at the Pollinator Hive, we loved seeing the beach volleyball matches at the base of the Eiffel Tower, the opening boat parade along the Seine (though the swims in that river were, well, icky), and the fencing matches at the Grand Palais. The gorgeous, historic city was itself a star, alongside Simone Biles and Leon Marchand. I contemplate Paris, or any great old city in this lovely and flawed world of ours, and I wonder: what can product pros learn from studying everything that goes into making a city thrive?

Cities like Paris — or like mine, Minneapolis, and like yours, wherever it is — have entry points and boulevards, pathways and planning, histories and layers, memories and futures, perils and havens — and of course cities are teeming with people, who have needs, jobs, lives, and joys. Effective cities are managed, over time, to be systems of economic value and human community and productivity. That’s not a bad description of what our digital products are, too.

So I wondered, as I thought about Paris, the city of light: what if in product work we referred to destinations, zones, spaces, homes, workplaces, monuments, utilities, regulations, rights, private spaces, public spaces, sojourners, and residents? Would our product-making be better? Would we be less hung up on vanity measures of doneness, since when is a city done? Would we remember our users, since what is a city without its people?

I’m not saying city planning is the only metaphoric frame product managers should use. But I do encourage us to try it. I also like product-as-garden (seeds, growth, prune, tend, harvest), and product-as-theatrical-production (characters, plots, directors, transitions, audiences).

I’m curious, readers: What are your own favorite mental models and metaphoric frameworks for this product work that we do?

On to the garden,

NOTE: This August 2024 issue marks the one-year anniversary of The Pollinator. We’ve decided to keep this thing going for a while, so we’ll be making a few improvements to our garden. If you visit us at http://pollinator.solutiondesign.com you will notice a new logo, designed by SDG’s Head of Design Adrian Stuart. It’s pretty awesome. So is Adrian.

Around the Garden

Our product opportunities don’t just arise from our users’ problems 

Check it out: You’re Not Just Solving User Problems, Itamar Gilad

I love encountering something that causes me to reconsider my assumptions. This article from Itamar Gilad does just that.

There are things about product work that I believe are foundational, perhaps non-negotiable. Of course we start by listening to our users. Of course we spend time in the problem space before entering the solution space. That’s what wise product pros do.

And yet — should we? Or more accurately: should we always start with our users and their problems?

Gilad reminds us that product ideas sometimes must come from outside the conventional source, our users’ problems. Wisely, Gilad roots this thesis in product’s duty to create value for users that returns value to the company. He recognizes that “the company has plenty of needs of its own: generating revenue, growing market share, lowering costs, fending off competitors, meeting legal and privacy regulations, maintaining and scaling the software, and much more. The product organization is expected to contribute to all of these.”

His article’s focus on things our customers may not care about is provocative to those of us who obsess over understanding and satisfying our users, but it’s a smart approach.

Gilad also outlines these alternate sources of product ideas and priorities.

If you think solving problems that our users never encounter sounds like product blasphemy, read Gilad’s piece. I think he’ll convince you to augment your user research with other sources.

To shift from projects to products, start with your funding models

Check it out: Project vs. Product Funding, Jennifer Pahlka, Niskanen Center

Pollinator readers are surely familiar with contrasts between project and product models. At SDG, we have spent decades working in both models, and we’ve consulted extensively with companies shifting from one to the other.

Much of the tension between these models comes from the way organizations fund technology. Indeed, the relationship between finance and product — I call this the Value Alliance — is among the most important but most overlooked relationships in business.

Jennifer Pahlka is a product and strategy veteran with impressive experience in a unique domain: technology for government policy. Governments tend to operate with rigid funding models, dealing with appropriations and proposals and tight budgets. It’s not a dynamic that’s naturally suited to agile product models. Pahlka’s article, unlike most project-to-product reflections, focuses on this often overlooked factor, the funding process.

I especially liked some specifics of Pahlka’s language. I’ve read a lot about project vs. product models. Heck, I’ve written more than my fair share about this dynamic. Pahlka uses rich terminology and imagery, like describing a project model’s “episodic large investments” and “abdication of responsibility to vendors” and explaining how in a product model, “the walls come down” and “customers [are] integral all the way through.”

The best part, though, are her straightforward charts and diagrams, comparing how projects and products are funded, like this.

She even includes a link to a Google Slides deck that includes all her diagrams and resources.

One gap in her essay: I wish Pahlka explored cap/ex accounting rules that govern capitalizing technology investments. Any organization will need to consider these rules and practices when considering shifting from project to product models.

But in general, if you are trying to make the case for (or understand the case for) shifting your org’s approach to funding, especially in government or similar domains, I suggest you check out Pahlka’s newsletter.

Design Systems as a product manager’s tool

Check it out: The Great Product Unlock: Why Product Managers Should Champion Design Systems to Supercharge Production Operations, Richard Banfield

Design systems are the collected standards, guidelines, and interface components that ensure consistency and efficiency in a product’s or website’s interface. Almost all professional modern web teams use design systems and UI libraries to build and sustain their products.

In this lengthy article, Richard Banfield posits that design systems are a product manager’s tool, just as much as they are a designer’s. He advises product managers (PMs) to use design systems to “unlock” capabilities of ideation and ROI exploration.

Banfield focuses on case studies and ROI statistics that will help you make the business case for investment in robust design systems and pattern libraries. He also lays out some categories of advantages that these systems provide:

• Dynamic Documentation

• Component & Pattern Management

• Design tokens & theming

• Prototyping & composition

• Permissions & controls

My one objection to Banfield’s article: his suggestion that design systems are recent innovations. (“The pain we all feel in digital production can be resolved with a more unified platform….But is this even possible? Until recently, the answer would’ve been no.”) In my experience, high-quality digital teams and product managers have always used centralized design systems to ensure reusability and to enable cross-platform communication, consistency, and updates, back to the Web’s earliest days.

That’s a small objection. The rest of the piece is gold. Keep it on hand if you need to make the case for investing in design systems.

The Product Manager role in 13 words

Check it Out: What is the Real Job of a PM (Product Manager)? (YouTube Video), Shreyas Doshi

This YouTube video from Shreyas Doshi will only take a few minutes of your time. Doshi, a seasoned and well-known product executive and consultant, lays out his definition of a product manager’s job in a few brief words.

I actually think he might eliminate “across the organization” from this definition to make it even pithier, but that’s a minor suggestion. And I really like the two-step emphasis on, first, defining the product and, then, orchestrating the actions to enable its success. Orchestrate is a strong word to describe what good product managers do, isn’t it?

All in all, this is one of the better brief definitions of the product manager job that I’ve ever seen. I suggest you watch the video for the full explanation, and then commit Doshi’s definition to memory. I already have.

Outside the Box

If you’re hoping to keep the Olympic flame aglow even though the games have ended, check out Statista’s Olympics data visualizations and analysis. It’s a trove of interesting statistics about the quadrennial global celebration of athletic excellence. I liked using it to explore some lesser-known facts. For example, I learned that while the USA has won the most medals all-time, the country that has won the most medals per capita is The Bahamas, which has won 55 medals per one million citizens.

Check it out at https://www.statista.com/topics/12442/paris-2024-olympics/#topicOverview

About the Pollinator

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

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

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

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