Years ago, I had an amazing job leading volunteer trail crews deep into the backcountry of Washington’s Cascade Mountains. These intrepid volunteers were invited to operate sharp tools with little more than a strong emphasis on safety, some oversight from me, and a battery-operated radio that worked on a mountain-based repeater system. We often didn’t know much about the work before we got there, apart from a very high-level description of ‘logout’, ‘brushing’, or ‘drainage’, so we solved a lot of problems on the fly. The work was exciting, and the risks were…manageable. Our trip coordinator’s sage advice still sticks with me: “Don’t forget your can of calm.”
Product architecture development can similarly be exciting and uncomfortable for the business leaders, marketers, designers, and engineers involved. It’s exciting, because teams have a blank slate to determine how to best meet their objectives, whether those are to address their customers’ pain points, expand into new markets, or create brand new product categories. However, the ambiguity at this stage of product development can be intimidating. Will our customers like this product? How big will it be? How well will it perform? We’d love to have a crystal ball for eliminating uncertainty and predicting the best product definition. But instead, we have our ‘can of calm’—our development approach—which makes the ambiguity of defining innovative world-class products less intimidating.
The Philosophy
Our flexible development process includes a guiding philosophy that applies to almost any new product, and serves as a map to help us navigate ambiguity.
A product matures through development as risk is deliberately identified, prioritized, and addressed.
It’s based on many decades of collective product development experience, and it really is that simple. But, how do we actually follow the right path on the map?
The best way to reduce risk is through focused learning, and the best way to progress maturity is through deliberate decision making.
Learning informed decision-making is our most reliable compass for navigating ambiguity.
Imagine bringing your team together to define a new product: ask them to list everything they don’t yet know about the product, and each big decision they’ll need to make in the process. As the team exposes these unknowns, they will determine how to prioritize learning and navigate the ambiguity.
Architecture Development Spans Multiple Maturity Stages
In most of our projects, architecture development progresses through the Discover, Define, and Evolve maturity levels. Through that process we
- identify & understand the opportunity;
- identify possible concepts to satisfy the opportunity; and
- de-risk innovations in a focused way.
As we advance product maturity through these early stages, we distill a wide-open funnel of possibilities down to a small number of high-confidence options, while building an understanding of the overall solution space. In this way, we deliberately navigate the ambiguity while dramatically increasing the resilience of the development effort to inevitable downstream requirement changes. We also deeply understand each product design before we begin large pre-production builds, leading to far fewer high-cost changes in the New Product Introduction stages of a project, which decreases overall development costs.
The Discover Stage
The Discover stage is all about understanding the opportunity and context around it.
We work closely with our clients to anticipate major decisions and find tradeoffs that lurk beneath the surface. We dig into core business needs, objectives, and constraints in order to balance timeline and cost considerations with the critical elements of brand reputation and funding events. We identify the stakeholders involved and work to understand the primary drivers of the value proposition from each of their perspectives, often involving them directly in the process. These drivers may include specific interfaces, experiences, costs, reliability, and others. These activities help us define the value context of our efforts, resulting in a set of assessment criteria we can use in early decision making.
We often help identify new stakeholder groups, undefined constraints, and other critical business case questions that might impact concept assessment. We couple these critical questions to major product definition decisions, making them tangible. At this stage in the game, we work with our client to determine the best way to fill these gaps, often deciding to share a significant amount of the work.
The Define Stage
The Define stage is all about identifying candidate concepts to address the opportunity.
We’re primarily interested in context and possibilities, knowing that major decisions are coming soon enough. If the product is connected to a larger ecosystem, we dig into that. We tie this together with our deep understanding of the product’s field of use, primary users, and functions that are critical to its value proposition. Then we’re ready to begin investigating details of the user experience, industrial design, feature set, and technical feasibility from different perspectives.
Once we better understand the ecosystem, use scenarios, characteristics, and functionality, we dig into regulatory requirements and other critical considerations for early concept development, because they weigh into major product definition decisions. Our goal is to fill in the context early to avoid unexpected requirements that force major design changes later in development when it’s much more expensive to address them.
This learning work results in a list of target requirements and a large set of concepts that we refine over time through iterative stages of downselection. At this point, we can confidently evaluate concepts with limited technical research and analysis, low-fidelity prototyping, informal user validation, risk assessment, and consideration of what’s routine versus innovative. In the Define stage, we downselect concepts by assessing relatively straightforward tradeoffs, while better understanding the solution space and preparing for the more difficult tradeoff decisions coming later down the road.
The Evolve Stage
The Evolve stage is all about de-risking the innovative elements of our candidate concepts to arrive at a winning concept.
We dive deeper into the details, focusing on the ‘hard parts’ of the design to learn about performance, weaknesses and failure modes, and realistic costs. We may split these ‘hard parts’ out in different ways depending on the nature of the product, but we’re most often addressing specific components, subsystems, and subsystem interfaces or integration points. We continue to refine our evaluations for downselection in each iteration, often via more in-depth design simulation, physical experimentation, and higher-fidelity user validation testing.
At this stage we have multiple concepts or ‘architectural configurations’ in play—we’re not working with a single concept simply to ‘make it work.’ As engineers, we are easily enamored by certain concepts (often our own), but we cannot play favorites during this stage. We’re developing innovative subsystems and products that nobody’s built before. We focus on specific learning to fill in the blanks around these new concepts, allowing us to identify the weakest concept candidates, flag critical tradeoffs, and support decision-making.
This is where decisions get really interesting. The knowledge built through the Evolve stage allows us to refine the higher-level requirements outlined in the Discover and Define stages. We think of most requirements in terms of ranges during these early maturity stages, and our learning work informs the comparative value of product concepts and the tradeoffs between them, which makes major product definition decisions easier to resolve.
Imagine that a concept moves through the Evolve stage meeting all target requirements except one: it is 0.5 millimeters thicker. Is it acceptable to adjust the thickness requirement? Let’s examine the tradeoffs: does the concept significantly extend battery life, appreciably reduce cost, or allow the addition of an affordable high-value feature? If yes, then we can likely embrace this adjustment and move forward.
Architecture Development Tools
You may be thinking, “I thought this was going to be about architecture development! What about requirements, partitioning, interface definitions, system modeling, and traceability? Where are the block diagrams?”
At Synapse, we use a variety of systems engineering tools and methods that support our development process. In another post, I’ll talk about the V-model, requirements development, risk management, and our methods for describing system functionality.
For now, I’ll simply mention that we use systems engineering principles to help us organize our learning, identify sound product architecture concepts, and clearly define tradeoffs. Doing so allows us to empower each of our clients to make well-informed decisions about the value proposition of their product—the balance of form factor, feature set, user experience, performance, reliability, and cost. That reasoning allows us to grade our systems engineering approach for each project and its particular circumstances.
Your Unique Development Strategy
Each project is unique. To tailor the development process, we consider the constraints, objectives, risk profile, and other critical strategy levers of the opportunity. We can then determine the best path through the maturity stages.
Product architecture development very often takes place over three phases spanning the maturity stages we’ve discussed:
Phase 1: Discover and Define stages
Phase 2: Define and Evolve stages
Phase 3: Evolve stage, peeking into the Develop stage
Let’s consider two examples of very different companies, and how we might tailor the development process for each.
Client 1 is a cash constrained startup with relatively high risk tolerance. Our team clearly defines what it means for their product to leave each of these maturity stages. We emphasize minimum viable product definition in the Discover and Define stages to ensure we’re not putting effort into low-value features. We often do a limited amount of learning in the Define and Evolve stages, focusing more deeply on a narrow slice of the solution space. This allows us to make informed product definition decisions as best we can while still recognizing the risk we’re carrying through the project. As long as we collectively understand the risk, we can develop mitigation strategies to address them downstream if necessary.
Client 2 is a well-funded product team in a Fortune 100 company with low risk tolerance. This group is particularly driven by brand reputation. These factors drive our team to do more focused learning work during the Evolve stage to set up the final design concept for success in terms of performance, reliability, and cost. Focused, rigorous work in these early days pays dividends during pre-production stages: we avoid late-stage changes due to major design issues and can efficiently verify the design and mature the manufacturing system.
Wrapping It Up
Hardware product development is famously ‘hard’, a reputation driven by long iteration times, large investments in manufacturing, and high costs of late-stage change. The ambiguity of business case and product definition in early stages is understandably intimidating in this challenging environment.
We have the tools to navigate this ambiguity and arrive at winning product concepts and architectures:
- The ‘map’—our philosophy that a product matures through development as risk is deliberately identified, prioritized, and addressed.
- The ‘compass’—guides us to reduce risk through focused learning, and progress maturity through deliberate decision making.
This approach helps us rapidly build confidence that the product is right for the market, that we have the right solutions in play, and that we understand the solution space. If anything shifts under our feet, we bring the ‘can of calm.’ We have twenty years worth of trips into the product development wilderness, building new trails and navigating the unknown. Our flexible product development approach continues to guide us through the ambiguity to deliver successful products for our clients.
Podcast
Insight
