Downer of a system

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.

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.

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