Setting the edges

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

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

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

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

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

First, our own perspective:

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

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

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

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

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

On to the Garden,

Around the Garden

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

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

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

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

Helpfully, she rates these methods using three variables:

• Completeness

• Independence

• Balance

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

Indeed.

An example of a team that’s done it

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

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

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

Three methods for identifying your product

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

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

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

• By business process

• By system

• By a combination of technology and product

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

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

A perspective from an HR professional

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

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

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

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

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

Outside the Box

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

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

About the Pollinator

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

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

• The Pollinator's editor is Jason Scherschligt, SDG's Head of Product. Please direct complaints, suggestions, and especially praise to Jason at [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.