Designing Product Teams for Outcomes, not Outputs

Too many teams are still measured by what they deliver, not the value they create. A chance discovery of a 2018 presentation by Rich Mironov—reminding us that “distance is the enemy of insight”—struck a chord. Seven years on, his message couldn’t be more relevant. If companies want to maximise their chances of building the right things, they must rethink some tired product and org structures.

Much of what Rich mentions are situations I’ve encountered since returning to Australia from Silicon Valley a few years ago. Rich has a no-nonsense way of getting to the point, and this presentation is no exception. His slides nail it.

https://www.leadingtheproduct.com/blog/how-to-structure-product-management/ 

Too much "distance", too many handoffs. What we need to avoid. But this model plagues IT shops.

Distance is the Enemy of Insight

The message is simple: “Distance” is your enemy. Rich talks about how conversational distance and the corresponding handoffs between your users/customers and the product team are the enemy of insight. Insight is the most critical determinant of success. Without direct first-hand customer/user insight, how can you confidently build the right things?  You can’t. And, of course, no amount of execution brilliance in your delivery will help you if you don’t have the required upfront insight with your users/customers to build the right things.

But Why?

Why do you need insight? Back to basics. You’re trying to create value for your customers through a product or service that works for your business. You’re hoping that value results in reduced churn, more customers, more revenue, or reduced unit cost. You’re looking for a successful business outcome. Your product outcomes should be traceable to those business outcomes and not be outputs masquerading as outcomes.

Nothing is guaranteed or assured when it comes to customers. You’re making bets. So how do you put the odds in your favour when developing your product strategy? You put your product team (product manager, designer, dev lead at the very least) close to your customers/users. They’re present and involved in the discovery interviews; and, through their cross-functional expertise, jointly solve the most pressing customer/user problems. You can’t do this with handoffs and imposed distance, and you can’t meaningfully iterate through POCs and hypotheses without being close and involving users/customers. This also opens the door for innovation. The engineers/developers know what’s technically feasible, and so are best placed to create novel and innovative solutions if they’re involved in the problem-solving. It doesn’t work when you toss them tasks or features via Jira—that’s just output.

Degrees of Distance

Back to Rich’s presentation. Rich’s first slide and narrative take us through five degrees of distance. He starts with the Grand Canyon of distance, with product/dev teams relying upon Gartner (or other analysts) as the proxy source of insight. Sadly, I’ve seen this belief/behaviour (coupled with the “Steve Jobs didn’t talk to customers” quip). Gartner doesn’t help you understand the unmet needs, priorities, and problems of your customers. It’s yesterday’s news. They don’t help you iterate around a problem to solve. This structure doesn’t work.

The next iteration is where sales and marketing step into the breach as the source. I’ve seen this, too. I’ve found it useful to sit in on sales calls and discover the customer catalyst or motivation to talk with us (was there an issue or incident with their incumbent solution that precipitated this discussion?). However, the sales team is there to close the deal, and they own the customer relationship. You want insights, but your questions may upset closing the deal. You need an out-of-band, non-sales conduit to your customers (but avoid contact while sales is trying to close).

The next model is all too common in IT circles and remote development situations. Stakeholders within the business talk with users/customers without necessarily understanding the viability and feasibility; they then send it over to a product owner who writes up and prioritises user stories in a backlog, which is then tossed over to developers as tasks or features to build. Do the developers have context? No. Is the PO aware of the customer/user problems? No, that was someone else. So how can you expect a successful outcome when those in the handoff chain are charged with outputs? You can’t. There is a lot of waste in building stuff that isn’t required with a less-than-desirable customer/user experience. I’ve seen this too—an unfortunate result of process triumphing over principles. 

Development Waste

It’s not covered in the presentation, but I want to call out waste for special treatment. Waste is the resource thief that keeps robbing you of value creation capacity. You’re robbed of capacity when you build those unnecessary features. I recall some surveys some time back that estimated 60-80% of features are rarely, if ever, used. I think Pendo.io was one source.

However, those features require ongoing maintenance, so you’re forever paying an ongoing tax on something you didn’t need. I found this out the hard way when I inherited leadership of a product several years ago. Several “shiny” features provided little value and had little customer traction, but required ongoing maintenance. I had to make the painful deprecation call, and then feature removal over several releases, which again consumed resources and some pain for a handful of customers using those features.

The lesson: try to avoid building the wrong stuff—you’ll pay for it at every turn.

Distance Nirvana

The final row of Rich’s “reducing distance” slide is where we want to be—a co-located product team with a product manager, a designer, and developers (and whoever else needs to be there depending upon the cross-functional requirements. E.g. an architect). That team needs to be involved in the customer/user interviews. You want them to hear the problems first-hand as each will bring something different in solving the problems and addressing the opportunities. 

Desirable Product Structures

The “Product Structure I Like” slide depicts a structure best positioned to achieve successful outcomes. Small, stable (not from a pool), and complete development team with product manager and designer that frequently communicates and iterates in non-sales conversations with representative customers/users—everything and everyone required to solve problems and deliver outcomes. 

A better way. Product manager, designer, development lead are teamed and in direct contact with users and customers.

The Problem with IT Structures

The final slide, “Product Structure I Hate,” closely represents the organisational structure problem plaguing many/most IT shops. Lots of handoffs; lots of distance with roadmaps full of tasks and features with arguably foggy traceability to problems and opportunities. I’ve seen this first-hand in transformations.

While some in IT aspire to shift to a more effective model, it’s tough. IT serves the business (and its stakeholders), not customers—the business owns the customers.

I’ve seen IT shops move from Project funding to Persistent (Product) funding, focusing on delivery efficiency. However, delivery and operations are all they can do without the organisation empowering them with direct customer/user relationships. The business won’t hand that over unless there is absolute trust coupled with executive-level aircover and sponsorship. Upskilling in the product management and designer domains while initiating a few manageable pilot teams to iron out the organisational nuances and build trust (evidence), is one possible way to move forward. 

Product Teams and The Product Operating Model

Rich delivered this presentation in March 2018—seven years ago. The message is as true now as it was then. Sadly, I see the same old structure problems continuing today.

I was involved or led several products during my 19 years in Silicon Valley. Every product except one followed the “product structure I like” model. Engineers, product managers, technical marketing, (but arguably not enough designers!) were collocated. We were trusted and empowered to determine which problems to solve and then solve them. It was business as usual.

Of course, it’s not business as usual everywhere else. Product management isn’t as mature in Australia as it is in Silicon Valley. There’s a burgeoning tech scene in Melbourne, so there are pockets of good, but overall maturity has some ways to go.

The “Product Structure I Like” slide bears a striking resemblance to how the tech giants structure their product teams (think Amazon’s “two pizza team” model). This is no accident. Successful and large-scale tech companies have found the most effective way to scale their product practices while delivering valuable outcomes and not resorting to onerous processes.

Over recent years, these principles have come to be known as the “Product Operating Model” and are practised by “Product Teams” (versus “Delivery Teams” and “Feature Teams”). It’s a set of principles, so there are and will be variations—not rigid processes that plague and inflict cognitive overload in so many other places. Marty Cagan and the Silicon Valley Product Group folks have popularised these terms through their books, blogs, and podcasts. In their 2023 book, “Rewired”, McKinsey refers to organising around “cross-functional Product Teams or pods” in the same vein as Cagan and Rich Mironov.

There’s some agreement on the destination and language (although I disagree with McKinsey’s interchangeable labelling of Product Owner and Product Manager—they are different disciplines). 

In Summary 

Rich Mironov’s presentation may be from 2018, but the message remains painfully true in 2025. The gap between teams and customers—whether due to process, structure, or culture—continues to erode the ability to build products that truly solve problems. Companies need to shrink that distance.

Empowered, cross-functional teams—those with proximity to the user and shared accountability for outcomes—remain the gold standard. They’re not just idealistic; they’re essential. My time in Silicon Valley showed me this model works when trust, empowerment, and insight exist. IT has a more challenging problem, but it’s achievable. 

Australia’s product maturity is evolving, but there’s still a lot of ground to cover. Let’s stop mistaking outputs for outcomes and start closing the distance with sensible product team structures—one product team at a time.