December 25, 2015
TABLE OF CONTENTS
One of my favorite books on product management is Marty Cagan’s Inspired: How to Create Products Customers Love. Even though it was published back in 2008, the concepts it lays out about organizing software teams are timeless.
In it, Cagan talks about product management as the challenge of discovering a product that is valuable, usable, and feasible. It’s a great way to think about the role of a PM, but as a consultant, I’ve also found it’s a surprisingly powerful framework for diagnosing and fixing issues with software teams.
In my experience, a typical software organization is made up of three groups: the business, designers, and engineers. The specific roles these groups play and processes they follow vary from company to company, but what doesn’t change are the core strengths and concerns of people in each group. Business owners, designers, and engineers are all good at different things that are all necessary for creating great products.
What I soon realized is that the concerns of those three groups actually map directly to Cagan’s three aspects of winning products. Business owners focus on making sure the software is valuable to customers and the business. Designers care about the user experience and application flow that make the product usable. Engineers are constantly asking how the software will be built so that the execution is feasible.
So what does this say about what a highly functioning product team should look like in the ideal case?
The most successful product teams I’ve ever seen smoothly integrate members of all three groups in joint activities from the beginning of the project all the way through the end. These teams have engineers weighing in on the feasibility of product ideas. Designers on these teams are creating prototypes to validate usability and add clarity to discussions. During development, the business folks are managing backlogs and responding to technical feedback every day.
These teams succeed because all three groups and their respective concerns are being included and worked on throughout the process.
Teams that don’t successfully integrate business, design, and engineering tend to fail in very predictable ways based on how they separate the groups and their concerns.
Remember Conway’s Law? Loosely put, it says:
“Organizations are constrained to produce designs which are copies of the communication structures of these organizations”
By applying the transitive property to Conway’s Law (Thanks Mrs. Stein), it’s reasonable to assume that we can learn a lot about the teams and communication structures of an organization simply by looking at the designs they produce.
As a consultant, I have to regularly walk into organizations, each with its own unique teams, skill sets, tools, and processes, and figure out where things can be improved as quickly as possible. Instead of getting caught up in budgets, timelines, head counts, velocity, infrastructure, etc, my first step is usually to look at the work products the team has created in the past and see what they tell me about the relationships and communication patterns that might be the root of the problem.
Using this framework, there are a few different patterns which have repeatedly come up. Here are some of the more common ones.
You see this pattern most often in large Enterprises where big projects are staffed with a multitude of specialist groups working in a serial waterfall. They have talented staff in the business, design, and engineering groups but the groups work independently and in sequence.
The business group makes decisions that fulfill their responsibility (valuable), without regard to the other groups and floats those decisions down stream to design. Those decisions, made in isolation, create immovable constraints that design now has to work around to achieve their responsibility (usable). With luck, Design will hack their way around those constraints and produce a compromised UX, adding more constraints to the stream and floating the dirty water down to engineering. Sitting at the end of the line, Engineering has the hardest time delivering on their responsibility of making the software feasible.
In the best case, this process slowly produces mediocre software with clunky UX at unnecessarily high cost. In the more common case, it just fails.
This problem is a little harder to spot than you might think. Most companies will categorically deny that they run waterfall and their PMP certified Agile coaches will swear up and down that they run an “agile process”. Unfortunately, in most organizations that just means that they stand up during their status meetings and call their BRD’s “stories”. One way to tell if an organization falls into this category of failure is to look for the following signs in their products:
Some organizations are run by business / marketing people who really care about visual appeal and user experience. You see this a lot in media or marketing companies. The business owners work closely with designers to create flashy and unique websites and applications. Unfortunately, engineering is an afterthought and feasibility suffers. The first time the dev team sees the work it’s only 2 weeks before the scheduled launch, and the designs can’t be implemented without serious compromises. Some signs to look for:
Some companies are run by a combination of business and tech teams. These are the kind guys that keep two copies of “The Lean Startup” on their desks - one for them, and one for anyone who happens to talk to them that day. They understand their app’s value and have the development chops to get code into production quickly. Unfortunately, it’s their lack of attention to design and UX that leads them to fail fast and fail often. Some signs to look for:
These are just a few patterns of organizational dysfunction I’ve seen and their tell-tale signs. There are a few more variations, but they all stem from the same root cause: A lack of open collaboration between the business, design, and engineering teams that ensure products are valuable, usable and feasible (Thanks Marty).
I think it’s safe to say that most technical problems are actually people problems in disguise. The most successful organizations are going to be those that can evolve their processes and relationships to build the trust, transparency, and cooperation necessary for creating great products. These ideas aren’t new or unique. As a matter of fact they were the basis of real Agile software development in 1999, but they’ve proven surprisingly elusive for most organizations to implement.
As a diagnostic tool, this framework has been extremely useful for me to learn about the possible problems with our clients’ processes. If you’re still skeptical or want to learn more, send me a link to your team’s work product and let us guess how you might be organized!