Product Management principles lead the world in value discovery and delivery of custom software. But they apply far beyond that scope. If your team is “running the engine,” any engine, and it increasingly feels futile, if status reporting feels like tax forms for leadership, if your work seems disconnected from value production, it is time to consider a simple re-framing that can change everything about how we approach work.

As an industry, we’ve made a choice.

Product Management in an Agile environment is the future of software delivery.

As an industry, we’ve seen the error of scrambling a project team together to fulfill a charter first drafted 4 months before, only to disband the project team upon delivery to a hapless user. Across industries, software solutions are far more likely today to be owned, managed and continuously improved by a Product Manager working with a designer, tech lead, and long-term team. These teams have proven to be one of the finest models for continuous development of solutions that solve customer problems and create business value.

There are a few consistent attributes of a modern Product Management team:

• They are accountable for outcomes, not features.
• They are long-term, not assembled for a time-boxed project.
• They are interdisciplinary.
• They are responsible for discovering value and testing ideas.

There is a very big world beyond the halls of Microsoft, Google, and eBay. There are contexts that don’t require software delivery with a standard tech team. Around the next corner, I hope, is the realization that Agile Product Management concepts apply – and with far greater ease, in fact – to matters well beyond software development and delivery.

Indications That Product Management Is Appropriate

In a traditional product team in a software development setting a Product Manager, Lead Designer, and Lead Engineer work in tandem to understand user problems and business value. The rest of the team is likely to be comprised of front and backend developers and data engineers. But that’s only the team because of the software delivery setting. Set that aside and you can identify the attributes that make Product Management appropriate.

• There is a distinct product.
• That product can be associated with KPIs important to the business.
• Leadership believes that those KPIs are worth investing in.

That’s it. Some systems require or deserve little care and feeding. Some business functions are the same way. But most business processes, or groups of them, are engaged in precisely because they do add value.

A Broader Definition of Products

What’s a product? In a traditional software delivery setting, it may be the new store locator, or the ability to trade-in your car, or the ability to shop for a new car, or the financing service. Whatever it is, we expect it to be custom delivery of newly minted services: the result of research, intense discovery, more-intense design, and a great engineering effort.

Got it, and product culture is most critical in such areas: it is a proven method for discovering and delivering value.

But the governance and management of a SharePoint site is also about value: discovering what users struggle with, understanding what the technology can do, and combining these two knowledge domains to swiftly deliver the greatest possible value with confidence.

The process of ticket-taking and managing ushers at a local theatre is a distinct unit of the business model, and it too is open to the basic components of Product Management: discovering pain points or solutions, testing the ideas quickly, and delivering with confident speed.

The Governance Fence

The word governance in any IT setting comes with baggage. It is often seen as a bit like government: setting up ground rules and infrastructure. Governance is essential in several domains: data governance will either save you today or tomorrow. Depending on your organization’s profile (and, increasingly, regardless of it) security governance can save you daily.

But too often we see it applied to areas unrelated to rules and oversight. Teams that “govern” a portal, or internal applications, are not encouraged by that title to solve problems, increase value, or innovate. They are encouraged to write and enforce rules, and to create and save PowerPoint presentations about it. We can do better than that in almost any system, or any unit of the business model.

The Power of Ownership

Teams commissioned not to govern, but to own a system or process, are more inclined to act like a modern Product Management team. We can encourage such ownership teams to adopt a few basic principles.

• Identify Value Areas that define what their product can do, or create, or how it provides value. This breaks down the product into a few things we care about: four to eight items. With a sales enablement tool, these might be Quality Content, Sales Pitches, Analytics, UX & Search Tools. For a box office operation, it might be Ticket Sales, Ticket Share & Trade, Refunds, Floorplans, Schedules, and Crisis Comms. There are few rules. Keep it simple.
• Assign ownership. All teams need a chairperson, but outside of software delivery, ownership needn’t be unitary. It can be divided across specialties according to skillsets and roles.
• Establish KPIs for their product in each value area. Drop the acronym: you are looking for objective measurements that indicate satisfactory performance.
• Work in an Agile approach to prioritize and test value-creating ideas. Scrum, Kanban, it doesn’t matter much. Work iteratively in short sprints and hold yourself accountable to two-things: short-term focus and long-term KPI improvement.

That’s it. So little is defined there. Should there be one owner, or one owner per value area? What types of KPIs are right, and how many should there be?

Thought Logic and Product Management

There is an answer: the team should set aside all the formalities. They should set aside acronyms and worries about promises once or ever made to leadership. They should honestly reflect on the types of value their product can, does, or has promised to deliver. They should assign the ownership they as a team believe in. And KPIs are indicators of performance: that’s all. We must only select as KPIs those measures that, when poor reliably mean we have work to do, and when strong mean we’ve really achieved. Any iterative, short-turnaround methodology is fine.

What we don’t want to do is to dig up the old to-do list when it is time for a status report, after spending three and a half weeks fighting fires we believed were more important.

Thought Logic can support teams who want to move from governance to Product Management. Our consultants embed themselves within your team. We understand that your experts are the experts that matter, and we bring to the table the leadership experience to help your teams own, discover, and innovate. We drive value delivery every day, solving the most valuable problems first. And yeah, don’t worry: leadership will get their status report.