There are many different philosophies and management styles when it comes to developing a new product. Knowing and incorporating different concepts will help you continue to grow as a technical product owner and will increase your ability to successfully build, deploy, and manage software.
In this post, I’ll introduce four concepts that I’ve used in the past to shape and deliver software products successfully.
Brooks’ Law
In his 1975 book The Mythical Man-Month, Fred Brooks argued that “adding manpower to a late software project makes it later” (which became known as Brooks’ Law). He gives three reasons why this is:
- Software projects are complex, and it takes time for new team members to understand the complexity well enough to build anything of value. This is known as “ramp up” time.
- As new members are added to a project, the number of communication channels increases exponentially. This increases the risk of duplication of effort, and it creates more management overhead.
- Software is not a set of sequential, independent tasks that can be done more quickly if more people are working on them. It’s very different from something like planting trees, where you can decrease the amount of time it takes by adding more tree planters. As he said, “nine women cannot make a baby in one month.”
How can product managers use this?
When projects start missing target dates, the first thought is always to add more capacity to the team. Brooks’ Law dispels that notion.
In my experience, there are two effective ways to hit future targets after falling behind:
- Make Significant Process Changes – Process changes are difficult, even for smaller teams. Humans are creatures of habit, and breaking those habits creates discomfort. However, when a team is dedicated to delivering a strong product, they need to be willing to change. The farther behind your project is, the more drastic your process changes will need to be. For example, ask yourself if there is a way to split the team into two smaller teams. This can create more focus and reduce the number of communication channels.
- Cut Scope – This isn’t an easy task either. After all, you have a vision in your head about how this product will work. Nevertheless, the most important thing is getting the product into users’ hands. Then you can validate assumptions and either circle back and build the features you cut or choose to prioritize other work based on user feedback.
Henrik Kniberg’s MVP Analogy
When an organization is first starting to use Agile product development principles, it can be difficult to change old behaviors. One Waterfall behavior that lingers is the hesitation to release any features that are not 100% fleshed out.
A conversational tool that’s been helpful to reinforce the Agile product development process is Henrik Kniberg’s skateboard-to-car analogy:
While this is certainly an oversimplification of the process, it reinforces the desire to deliver incremental value throughout the development of the product. We can use that incremental value to test assumptions and get feedback in order to deliver more incremental value. Otherwise we’re throwing a dart at a dartboard before the real development starts and forcing that to guide our entire product development process.
How can product managers use this?
I’ve found this metaphor particularly interesting in conversations with executives who are more removed from the project minutiae. The oversimplification actually works to our benefit because it shifts the focus from building a giant, complex machine to figuring out how to pare the machine down to the core, necessary functionality.
This can also be a useful image to start the conversation on why it is important to get something out there for users to react to, as opposed to trying to build the perfect thing the first time.
Theory of Constraints Basics
The Theory of Constraints (TOC) was introduced by Eliyahu M. Goldratt in his 1984 book The Goal. It’s a management philosophy that originally targeted traditional industries like manufacturing. However, its concepts are now applied in a wide variety of industries. It outlines a repeatable five-step process to identify and alleviate bottlenecks in creating products.
How can product managers use this?
Alleviating Bottlenecks
Software project bottlenecks (resulting in developers sitting idle) happen for a few different reasons. The developers might be waiting for updated wireframes from a designer, for the product owner to get them an answer on a business requirement, etc. If this happens often, the project falls behind, and (as we noted in our first point) it can be difficult to catch back up.
In complex projects, it takes time to create requirements and designs. The more time it takes, the more likely we are to have developers idle. To keep the developers as the constraint, we should strive to build requirements and approve designs as quickly as is responsible. I do this in two ways.
- Set up a clear process to go from idea to finalized wireframes. I cover that process more in depth in The User Story Pipeline: A Visual To Guide the Agile Process.
- Constantly remind ourselves that Agile allows us to adapt to change quickly. If the majority of our assumptions are correct but some small assumptions are invalidated, we can make adjustments. The key is to validate the major assumptions, not to answer all of the questions before starting development.
Keeping Inventory Down
The TOC emphasizes keeping inventory down. If we think of “inventory” as anything that’s used to build the finished product but isn’t the finished product, we can equate it to uncompleted software features. Using TOC, we can say it is better to have one feature completely finished than it is to have two features each 50% working.
Human-Centered Design (HCD)
HCD is a way of thinking about your product in terms of three different perspectives: desirability, feasibility, and viability. When all three are used as inputs, the quality of your end product will be much higher. These three different perspectives help keep technical hurdles, usability, and end-users in mind throughout the product development process. They help us avoid a common pitfall — building a product that works for us but doesn’t work for the people that are actually going to use it.
How can product managers use this?
You can avoid this pitfall simply by listening. Listen when there are concerns from the tech lead on your project about the approach to solving a problem. Listen to your design lead when they express concerns about the complexity of a new user workflow. Work with them to understand the tradeoffs of different approaches, and try to find the win-win-win option.
We have a number of blog posts around human-centered design that you can check out to learn more about the process.
Hopefully, you can use these four concepts to improve your product management processes and build your next successful software product.