Creating Product Systems (part 0)
How to be a hit-making software company and ship repeatable, consistent innovation
Product Systems Quarter: Before you think about how to optimize your product team, think about the information in this series first. It’s a 3 part series with this intro. The next few weeks are dedicated to helping you optimize how your research and development (R&D) team is run - we will share both frameworks and practical tips. It’s a culmination of both our (Oji and Ezinne) personal and professional experiences and our lessons from running product teams and partnering with great Engineering, Design, and Marketing leaders to build kick-ass products.
— — — — —
“Hit or miss”
In the 1990’s Microsoft decided to get into the personal finance software business, after a failed attempt to buy Intuit in 1994. This was a grave threat to Intuit. Microsoft had a history of getting into certain niches, like office productivity, and using its existing market power to drive out incumbents. Intuit didn’t roll over though. It stayed close to customers and consistently out-bet and out-shipped Microsoft, even though it had really smart people and much deeper pockets. Today Intuit is still at the apex of personal and business financial software and Microsoft gave up that market completely after losing to Intuit for many years. As someone who had a front-row seat (I was at Microsoft at the time and was friends with the PM who led MS Money), Intuit’s secret was having a great system in place to build products that their customers really wanted and would pay for.
High-growth software businesses need to be hit-makers. To do repeatable, high quality innovation that leads to successful and impactful products, PMs and product leaders need to create Product Systems.
Product Systems are all the practices, processes, principles, tools and rituals that help ensure high quality products and how they connect to create a culture of consistent customer-driven innovation. It's the deliberate approach you use in product management teams (and by extension the research and development ( R&D) teams) to consistently build great products.
Product Systems must be designed with intention. In order to keep pace with change, scale, people and culture, product systems need built-in feedback loops to refine our approach to solving problems over time. Intuit’s product system wasn’t just about product management. It extended into engineering, design, and go to market; and how these worked together, hand in hand.
After enduring years of delayed projects and cost uncertainty in delivering software, software engineers figured out that breaking up projects into smaller pieces and dynamically grooming the tasks was better than the traditional waterfall process, which attempted to estimate unknown engineering variables far out into the future. These became what is generally referred to as the agile methodologies that have been with us now for decades and are now pervasive in engineering practices (flaws and all).
In similar ways, product managers are starting to realize that we need better systems for producing innovation that consistently nails the customer delight and business success that we are tasked to deliver. We are starting to notice that it can be quite hit or miss at our elevation of product development i.e. above the engineering code and sprints. Many teams are happy with nailing it 50% of the time, spending the rest of the time building things that don’t move the needle. Running in place and doing needless retros. What if we could institute the conditions to increase the hit rate? Not as a guarantee, but more like a Petri dish of higher probability of good outcomes?
We have to routinely consider the following: a) what are the biggest problems to solve to accomplish customer and business goals, b) what is the best solution to build to deliver on the customer problem and opportunities and c) what is the best sequence to deliver it in, for maximum customer and business impact. However many of us have been on teams where we have shipped things that don’t matter; software features that will go down into a black hole of lost productivity for your team and almost no consequence for your customers.
The negative opportunity cost of this hit or miss quality of much of current software value delivery means investment in features that customers don’t particularly care about; which entails waste and mismanagement of resources. We never tire of reminding PMs that each individual PM routinely helps direct the efforts of upwards of $1 million in people resources (developers, designers, PMM, technical writing, data science, and more).
In this series (which will be part of a forthcoming book on product management) we lay out what a product system is and why it has to be a deliberately designed and evolved entity in any R&D organization that is tasked with software creativity. Let’s dive into how to think about product systems for next-level product teams.
“This is the way it’s always been done”
Product systems always exist in some form, but they may be informal. We found many informal systems at Calendly, Discovery Inc, Atlassian, and more. As head of product for Atlassian’s communication division, I struggled with managing far-flung dependencies which was a major feature of Atlassian product development. As VP of an incubation team at Time Inc, Ezinne struggled to define how to build within a scrappy innovation initiative. In both cases, existing ways of working didn’t seem very efficient or tuned for the best performance. These experiences illustrate that there is always a system in place, but it could be designed better. In fact, most R&D organizations stumble into a system and kind of just use it and maybe tinker around the edges a bit as they go, because it’s been working well enough most of the time. Or its problems often go unnoticed, because the current rituals have become customary or no one knows exactly how to change them.
In addition to this, there are a few other good reasons why product systems may not be an explicit area of active design in most R&D organizations:
There hasn’t been an explicit conversation of an analysis of what is being used. We are barely aware of product systems in their entirety, because they are a system of systems. The component parts just seem to happen - squads, scrum, meetings, useful PM frameworks, etc. Historically whether and how we use these things are independent decisions that are unconnected from each other.
Often inception product leaders implement a system, or parts of one, from previous experiences. The team inherits, tinkers, and uses the system, even when the product leader has moved on, because they still sort of work. But ongoing revision stops.
The system calcifies. It made sense, was approved and/or was successful at a point in time but the team cannot explain, prove or recount the purpose. The system evolves into a culture with a lot of people invested in keeping it the same.
Change management is hard. It's also pretty difficult to change a system that is used by tens, hundreds or thousands of people. It can be hard to justify the time and effort to re-teach and retrain. It can take time to convince R&D leaders who are wary of lost productivity when the end result can be hard to quantify effectively.
You already use a product system or parts of one. It has its advantages and is undoubtedly delivering value to your R&D organization. However, we hope to expand your definition of what is part of the system and also ingrain a constant improvement mindset to it. We will explore the dimensions of good product systems so you can be more mindful of your own.
Breaking down the part of a Product System
Product systems can be broken down into many sub-parts, our craft is a multitude and variations abound in software and the hard economy, like in retail and manufacturing. For simplicity, we have chosen to break them down into 3 main systems. You might make connections to what exists in your own organization and you might also naturally group them in different ways for yourself. That’s ok. The grouping is not the most important thing, the intentional design is:
There are systems of People & Management - how we deliberately get the most out of the talent we have, especially PM talent.
There are systems of direction setting and strategy - how you choose what to go after so you can focus an r&d organization.
There are systems of Execution - how we repeatedly build things that customers love and the business celebrates.
In a high functioning R&D organization a) you will find people who innovate faster and better than your product system implies b) you will sometimes need to make exceptions (to go fast, when needed) that still contain the spirit of the system. That’s Ok. Adopt the improvements. Document the exceptions when they work well and distill the essence of the context for which they worked. Any systematic process is always in service of and subservient to faster and smarter innovation and not the other way round.
The most important ideas in creating product systems are twofold:
They are necessary and need deliberate design and maintenance.
They MUST be malleable and changeable or they will not serve the organization very long.
Conclusion (of part 0)
Whether it’s explicit or implicit, a product system is used constantly (it's a high traffic concept) and thus it's a high leverage point in how you make software. A good product system is usually opinionated and often encapsulates many product practices within it and should make good product decision-making the default. It prevents your R&D organization from making the most egregious mistakes and makes it so that when they do, you have a good shot at finding and fixing them quickly.
A good product system allows you to harness the outlier talents in your organization, but it also makes it easy to make full use of averagely skilled employees or professionals who are earlier on in their career path and don’t have as much experience of what good looks like.
Product systems are the floor of the process of innovation, not the ceiling. In essence, they serve as innovation insurance.
We believe a good product system is essential to winning in a competitive software market.
So what’s your experience with Product Systems in your organization?
Does the way people work to build stuff make sense and encourage the right kind of innovation and velocity? Or is it a fight to get things done well. Our experiences are just one of many. We’d love to hear about yours.
Have you analyzed your current system? What was your process? What did you learn? Hit us up in comment or at ideas@productmind.co or just comment below.
Read the rest of this series on Product Systems.
Below we’ll share the rest of this series of posts as they’re published. Book mark this joint!
Systems of people and management - part 1
Systems of strategy and direction - part 2
Systems of execution - part 3
Amazing article, can't wait for the next parts!