I. What is a “product”?

What do we mean when we say “product”? A “product” used to be a standalone tangible object. For example, a chair, a car, a refrigerator, a telephone or a thermostat. In the mid-20th century, leading product designers such as Raymond Loewy and Henry Dreyfuss focused on external appearance or style, as well as ease of use and manufacture. They made beautiful objects that did a specific job and, once manufactured and sold, never changed until the next model was created. Businesses organized teams around the management of one or more products. Profit came from the one-time sale of individual units.

But what a product is has changed. The app I download, often for free, is a product. When I use it to hail a ride it’s part of a larger experience, arguably the true ‘product’ Uber and Lyft deliver. The phone I use is a product, one that is a sophisticated package of metal, glass, electronics, operating systems, wireless communication, apps and more. When I use it to play music or watch shows from a subscription streaming service it’s part of a larger system. This interconnected set of products, technologies, services and content is often called an “ecosystem.” Arguably, from an end-user perspective it’s all part of the same thing. It may be come from one or more brands and involve interacting with multiple different systems, but it does what they want it to do. In this world the boundaries between discrete “products” start to break down, and the notion of what the “product” is starts to expand.

Take another example. A Wi-Fi smart thermostat with remote sensors, a mobile app, integrated with Alexa, Google and Siri, with an energy saving service provided through a local utility, and a feature that analyzes the health of the furnace and air conditioner and reports it to my local HVAC professional is, all together, a singular offering. For customers, it starts with the purchase of the thermostat hardware device and quickly extends into mobile apps, web sites, and software-based services provided by the thermostat manufacturer and other companies. While any one customer might not use every feature, it’s all there and available. More importantly, it all needs to be designed, developed, managed and maintained. 

Building this “thermostat” takes the collective effort of multiple teams working across hardware, software, cloud services, data analytics, partner integrations and more. All their efforts need to come together to make the product successful. An old-line, hardware-centric company that sees the physical device as the primary element will naturally organize teams and prioritize decisions around hardware. An internet-era, software-centric company will likely see the physical device as an important interface but organize teams and prioritize decisions around the software platform. In any company, different teams are working on different components, some unique to this product, others shared between multiple products across a larger portfolio. Each team likely reports to different managers reporting up to different parts of the organization, each with their own goals, incentives and performance metrics. Ideally, everyone across the organization is well aligned to deliver an integrated high-quality product, and an easy and delightful user experience. Sadly, reality is often far from ideal. 

Having spent many years designing, developing and releasing smart home products at Honeywell – an old-line, hardware-centric industrial manufacturer – I’ve experienced the challenges of building these new types of products. I also came to truly appreciate how our collective thinking defined so much of how we approached product design, development and ongoing management. At Honeywell, most if not all our challenges could be traced back to mismatches between the realities of building these new types of products and our collective industrial-era thinking and practices. While the products had changed, the thinking had not. It’s time for an update.

The Whole Product Stack

Networked products, like a Wi-Fi smart thermostat, are not discrete products. They are a collection of highly interrelated components and systems, each depending on the other to deliver the features, benefits and end-user experiences. On their own, these components don’t provide much direct customer value. Only as a whole do they become valuable. As designers, engineers and product managers, we need to focus on each component while ensuring the whole comes together. We need to see the forest and the trees, and make it all work together.

The whole product stack offers a model for understanding both components and the whole. Let’s look at the basic elements of the stack. Then we’ll look at the key elements that run across it.

There are 11 basic layers in the stack, they are:

1. Mechanical

2. Electrical

3. Firmware & Embedded Software

4. Connectivity Style

5. Embedded User Interface 

6. Device Design

7. Cloud Platform & Services

8. Algorithms & Intelligence

9. Mobile & Web Apps

10. Third-party Integrations

11. Services & Extensions

Let’s cover a bit about each layer in the stack:

Note: These descriptions are necessarily high-level. Each element represent a much deeper set of design and engineering challenges. Yet, each is essential for the overall product to be successful.

1. Mechanical
The mechanical is all the physical parts that make the object customers see and experience - be it holding in their hands, putting on their walls, wearing on their bodies, etc. This is usually the domain of mechanical engineers and industrial designers, as well as sourcing teams, part suppliers and factories. Issues of shape and size are important, as are material and component selection, component cost and availability, and part manufacture and assembly processes. Tradeoffs between cost, availability, quality, and manufacturing processes are common. The number of units planned (aka manufacturing volume) impacts everything.

2. Electrical
The electrical is all the circuitry and components that make the device function, run software and generally come to life. This is usually the domain of electrical engineers and various specialists. Issues of CPU selection, memory capacity, circuit board layout, wireless performance, energy management and battery life are critical. “Head room”, or how much compute capacity is allocated for future updates and upgrades, is a critical decision balancing current and future features the hardware will be expected to support. Tradeoffs on component cost, availability, and quality are common. The size, shape and arrangement of circuit boards and batteries are a key dependency for overall size and shape of the hardware.

3. Firmware & Embedded Software
Firmware and embedded software are the software stack running locally on the device, including OS, applications, wireless connectivity (Wi-Fi, Bluetooth, 15.4 standards, etc) as well as background services like memory management, error handling and more. This is usually the domain of embedded software engineers and specialists. Choice of operating system is critical and highly interdependent with choice of CPU and electrical components. Tradeoffs are common between cost of electrical components, OS and application compute power requirements, energy usage and battery capacity. Choice of OS has significant impact on ease of application development and total scope of firmware engineering to deliver the end-user experience. 

4. Connectivity Style

Connectivity style is how the hardware device connects and communicates with the cloud. Does it use Wi-Fi and have a continuous, always-on connection? Does it only connect intermittently and turn the Wi-Fi on and off on a predetermined basis? Or does it depend on another device for network connection? These questions are usually the domain of firmware, wireless communication and cloud engineers, along with system architects. But connectivity style has far-reaching implications for the whole product, setting constraints and boundaries for software features, data collection and reporting, and the end-user experience. If the device is always online, then real-time data and interactions are possible. If the device is offline most of the time, the user experience is more limited. What’s right depends largely on the nature of the product.

5. Embedded User Interface 
The embedded user interface is how a user interacts with and controls the device. This is usually the domain of user interface and interaction designers, and embedded software engineers and developers. The embedded user interface is highly dependent on and determined by the mechanical, electrical, firmware, connectivity and overall device design. For example, the choice of display (type, size, quality) defines the constraints and opportunities for any visual screen-based interface. The type and number of buttons and/or other physical inputs similarly define how a user interacts with the device. Capabilities for sound, haptics and light add more opportunities for user interaction. Achieving a simple and delightful experience becomes a balance of everything. Embedded user interface is a significant crossroads for tradeoffs and competing requirements, goals and needs across the hardware device and whole product stack. It can be one of the most fraught and difficult spaces for teams to negotiate. Creating simple and beautiful solutions that can be delivered on time and work reliably requires a strong vision, team alignment and coordination across the whole product stack. 

6. Device Design

Device design is the shape, size, usability and aesthetics of the device. This is usually the domain of industrial designers and mechanical engineers, as well as experts in color, material and finish and human factors. Issues of material selection, assembly process, part fit and tolerance (or the allowable space between parts) are important. Tradeoffs between aesthetics, ease of use  and material cost, availability, ease of assembly, and manufacturing processes are common. Like the embedded user interface, device design is another crossroads for competing requirements, goals and needs across the hardware device and whole product stack.

7. Cloud Platform & Services

Cloud services and platform are the collection of APIs, data bases, applications and overall IT infrastructure that support, service and enable the connected device. This is usually the domain of system architects, software engineers and developers, IT teams and third-party services such as AWS or Microsoft Azure. The cloud is another massive crossroads of tradeoffs and competing requirements, goals and needs. It is often a major bottleneck for features, capabilities and user experience, and requires a long-term view and approach to investment and resourcing. Ultimately, whole product development and success is highly contingent on a well architected and managed cloud platform. For this reason, it needs to be handled with strategic care, a whole product mindset, and a long-term outlook.

8. Algorithms & Intelligence
Algorithms and intelligence are the foundation for product ‘smarts’ such as automated features, trend reporting and alerting. This is usually the domain of software architects, engineers and developers, but also product managers and business strategists. Algorithms can sometimes be treated like a product unto themselves with dedicated product managers and engineering teams. They can also be a space for new feature or product experimentation, and data or service integrations with new partners.

9. Mobile & Web Apps
Mobile apps and web-based software are the end-user facing experience of the product. This is usually the domain of software developers, product managers and UX designers. For many users, what they see on their phones and in their web browsers is the product. It’s the most visible and easily accessible part, and as a result can easily define success or failure for the whole product. It packages and presents all the data, features, connectivity and intelligence provided by the rest of the stack. As a result, it’s often where problems from across the whole product show up. The app can only be as good as the rest of the stack lets it be. Problems, bugs or limitations that appear in the app often have roots in other aspects of the whole product stack. Issues of UX design, front-end technologies, development and update frequency are common. Dependencies with firmware, cloud platform & services, and algorithms & intelligence are critical.

10. Third-party Integrations
Third-party integrations are how the product works with different third-party products and services such as Amazon Alexa, Google Assistant, Apple Siri and others. This is usually the domain of software engineers and developers, as well as product managers and business strategists. Issues of feature compatibility, UX consistency, and depth of integration are important. Cost-benefit tradeoffs are common in selecting which integrations to invest in supporting and maintaining over time.

11. Software-based Services
Software-based services are how the product provides additional value to a customer, generates new sources of revenue and opens new opportunities for the business. This is usually the domain of business strategists and product managers, but relies on software engineering and design teams across the whole product. Services can be treated like a product unto themselves with dedicated product managers and design-development teams. Service such as preventative maintenance, costs savings & rebates, consumable replenishment, upgrades and enhancements are common examples. Launching and supporting new services often present significant organizational challenges companies can struggle to overcome.

The Whole Product – Greater than the sum of parts
All the layers in the whole product stack are essential. The whole product doesn’t really work without any one of them. However, customers don’t buy into or fall in love with individual components. They buy into and fall in love with the whole. They may not use every feature. They may like some aspects more than others. But, in the end, all the layers in the stack must work together to deliver a clear customer benefit, strong revenue and business growth, and an engaging and delightful brand experience. No end user buys just the firmware or an algorithm after all.

II.

The challenge of integration
Making a whole product that works well, is stable and reliable, and can scale and grow over time is hard to do. Sometimes just getting the core technologies to work is a huge effort. But it takes more than knitting the layers together to build a successful whole product. It has to be done to deliver specific outcomes and goals.

There are several key elements that flow through and around the whole product. They include:

1. Product Vision & Prioritization 

2. Value proposition

3. Data Collection & Analytics

4. Cybersecurity & Privacy

5. End-to-end Customer Journey

6. Brand Experience

1. Product Vision & Prioritization
The product vision is the core definition and big idea behind the product. Having a clear vision, that is shared by everyone across the full team and wider organization, is essential. Without it, coordination across teams becomes almost impossible. Prioritization is coordinating the day-to-day delivery across the different teams working across the stack to deliver on the vision. Vision and prioritization are usually the domain of product managers, lead engineers and lead designers. A small team with clear roles and responsibilities, empowered to own the vision, roadmap and delivery prioritization, is essential for successful outcomes.

2. Value Proposition
The value proposition is the high-value problems customers are willing to spend good money to solve. This is usually the domain of product managers and executive leadership. But it’s the responsibility of the teams working across the whole product to deliver. No one element in the product stack delivers the value proposition on its own. Delivering this value, in a simple and reliable way, depends on all the elements in the stack working together. Which in turn requires the teams of people building the product to work together to deliver the whole, not just their own pieces of the puzzle. This is easy to say and hard to do well.

3. Data Collection & Analytics
Data collection and analytics are both a base requirement and a potential opportunity space with implications and dependencies across the whole product stack. This is usually the domain of data scientists but also software architects, developers, product managers and designers. Data is required for basics of product management including understanding existing customers, patterns of use, feature adoption, and customer engagement. It is the basis for ancillary services, such as cost savings and preventative maintenance. It is a source of insight, inspiration and development of future features, upgrades and product offerings. Tradeoffs between what data points to collect and store, and the investment required to enable data collection across hardware, software and cloud infrastructure are common.

4. Cybersecurity & Privacy
Cybersecurity and privacy are essential for any networked product. Media reports of the latest security breech offer examples of why it matters. This is often the domain of cybersecurity engineers and system architects, but needs to be considered a responsibility by everyone on the team. Security and privacy issues must be integrated throughout product design, engineering, and ongoing updates and enhancements. Protecting customers data and privacy is a never ending job.

5. End-to-end Customer Journey 
The customer journey is the sum total of interactions a customer has with a product, from how they first learn about it through purchase, setup, daily use, servicing, upgrades and add-ons. It’s not so much the product itself but everything that comes with it and around it. This is often the domain of product management, marketing and design. It includes how the product is marketed and advertised, how the hardware device is packaged and shipped, how customers are guided through setup and install, and how they get help learning and troubleshooting issues. The quality of each of these interactions cumulatively define the customer experience of the product. In the best case, this sum total customer experience is explicitly defined or managed for quality. In the worst case, it’s the result of discrete actions by different teams working in isolation.

6. Brand Experience 
Brand is how customers feel about a company and what they say about it to family, friends, colleagues and the world at large. Brand experience results from all the interactions customers have with a product and a company. This is usually the domain of designers, marketing teams and brand managers. But, it’s ultimately the responsibility of everyone in a company to embody and represent the brand in everything they do. For whole products this means ensuring consistency and continuity of visual design elements, editorial tone of voice and messaging across hardware, user interface, web, packaging, marketing, social media and advertising. It means developing features, integrations and partnerships that reflect the purpose behind the brand, and demonstrate the company’s commitment to those values. It means enabling customer support teams to deliver quality service to every customer. For the whole products, each layer in the stack has a role to play in building the brand. Which in turn requires the teams of people building the product to work together to deliver the brand.

III.

Designing across the stack
What customers see, feel and experience is the collective result of many individuals working together. Making the best possible user experience means integrating multiple components, working across teams, and synthesizing everything into a coherent “product” that is greater than the sum of its parts. It requires a different mindset, one that looks across the whole product and ensures continuity of vision, value and user experience across it all.

For designers, the challenge is to design for the whole product and ensure the core user outcomes, value propositions and brand promises flow throughout the stack.

If you’ve made it this far, thank you for your time and attention! I hope this thought has sparked ideas in your own mind. This is a first draft of a much larger idea. I look forward to evolving the thinking and frameworks with more conversations and discussions.

Want to share a thought or idea? Please get in touch.