This article was published on Medium.com

Product developments are becoming progressively more difficult. A primary reason for this is that the products being developed today aren’t just products — they’re complex, interconnected systems. A system is a collection of individual parts that work together to accomplish something that no single component could do on its own. The result of living in the “Systems Age” is nearly every product developed is both a system on its own, and works as part of a larger, interconnected system. Consumer electronics, vehicles, homes, buildings, process control systems, medical devices, software — it’s hard to find a product today that doesn’t fall into this category. This increasingly interconnected world brings new levels of complexity and challenge to both products and product developments.

Because of the complex nature of product developments, companies can easily find themselves falling into certain traps, but recognizing these possible pitfalls in advance can prevent headaches and ultimately improve timelines down the road.

Trap #1 — Forgetting the Iceberg Principle

The first trap is not fully understanding the problem that needs to be solved. Imagine a customer saying, “I need to be able to cross this river.” Think about possible concepts for solving this problem. What are the first, second, and third solutions that come to mind?

On the surface, all of these concepts sound reasonable. But how is it possible to determine which is better? Lacking additional information, personal biases, perspectives, and assumptions will lead to favoring one solution over another. Often times, the size of this problem is directly proportional to the level of a project manager’s experience and education. The smarter a PM is, the more likely they are to think they have the right answer, right away. This is a real danger when developing products. The problem is, the need statement is only the tip of the iceberg. It takes a conscious and determined effort to break through the ice to get down into the cold, dark water where the real requirements, constraints, desires, and aversions live. Once you do, you may find that best solution for crossing the river is actually swim lessons, which wasn’t even an initial consideration. Gaining a deeper understanding of the problem space prevents the possibility of wasting time and money, only to have to pivot away from that ultra-efficient hot air balloon the PM was so certain the customer needed. Few organizations do this well. Does yours?

Trap #2 — Jumping too quickly into design

Once a concept has been selected, companies fall into another trap — immediately jumping into design and implementation. Anyone who’s said any of these before has probably fallen into this trap:

The problem with moving straight from concept to design is it can unnecessarily constrain creativity, limit choices, and lock a PM into a specific implementation without the ability to weight the implications of that choice. And, while designing as many cool features into a product as possible is an option, those features could slow down processing. If what the users really care about is response time, the product probably won’t succeed. There is great value in creating an architecture and evaluating it against key performance criteria before becoming locked into a design. CB Insights did an analysis of 101 startup postmortems. Consider this quote regarding why Wesabe failed:

“Between the worse data aggregation method and the much higher amount of work Wesabe made you do, it was far easier to have a good experience on Mint, and that good experience came far more quickly. Everything I’ve mentioned — not being dependent on a single source provider, preserving users’ privacy, helping users actually make positive change in their financial lives — all of those things are great, rational reasons to pursue what we pursued. But none of them matter if the product is harder to use.” – Mark Hedland, Wesabe[1]

So how can considering architecture help? Take the example of creating a functional model. This allows for the evaluation and optimization of architecture based on what’s most important (see Trap #3 below) in a way that is 100% independent of any physical implementation. The functional architecture can be tested in terms of how well it responds to failures, and can then be adjusted accordingly. Use cases can be traced through the model to ensure the architecture fully supports them. An added benefit of this “scenario tracing” is that it helps to identify interface requirements and features that otherwise might not have surfaced until much later (when they are more expensive to implement). Having a documented architecture also helps troubleshoot problems, understand up- and down-stream impacts of proposed changes, and do early validation with customers and users. Architecture provides insights that allow for better informed trade-offs, smarter technology choices, and more thoughtful design decisions. Customers speak the language of desires and pains. Engineers speak the language of requirements and features. Architecture is the Rosetta Stone that ensures the translation between the two is accurate. Skip it at your own risk.

Trap #3 — Ignoring the “-ilities”

Engineers are great at considering what a product must to — the product’s capabilities. The third trap is ignoring how a product needs to do those things — the product’s characteristics. Many times, these characteristics are what differentiate products and determine long-term market success. Characteristics are the “-ilities”- things like usability, reliability, adaptability, scalability, maintainability, affordability, and producability. They often include things like safety, security, and compliance.

The world fell in love with the iPhone not because it offered some function that other smart phones didn’t. They fell in love because the touchscreen was sexy, cool, and intuitive. They kept coming back because the iPhone had the ability to host an ever-increasing number of apps. It was these characteristics — usability, novelty, and its potential for growth — that ultimately won consumers over.

It’s critical to know which characteristics are most important for a product. Otherwise, there’s a risk of creating a product with great features that fails because it can’t be efficiently produced, is too expensive, isn’t usable, or can’t be effectively scaled in the ways needed to grow your business. Can any PM afford to ignore the “-ilities”?

Summary

There is no silver bullet that can address every product development challenge. However, avoiding these three traps will place the project into a much better position for success. Want to learn more about improving your product developments? Contact Base2 Solutions.