Challenge
The Ford brand is synonymous with the trades and, for more than 50 years, has manufactured both the world’s best-selling pickup truck and van. Every day millions of people depend on Ford pickup trucks and vans to reliably execute their jobs and keep them safe while doing it.
But Ford wanted to protect their livelihoods too.
In 2020, the FBI estimated that the cost of stolen work equipment in the U.S. totalled more than $7.4 billion, a figure believed to be underestimated in stolen vehicle reports (U.S. Department of Justice, Federal Bureau of Investigation, Uniform Crime Report). While the figure is startling, the report doesn’t account for what we heard during our interviews with real tradespeople from the midwest. And for one user, an electrician, it isn’t just equipment or tools being stolen – “it’s like your whole livelihood has been taken.” Across this and many other user interviews, it was clear where Ford could help their drivers next. People choose Ford for its reliability; people stay with Ford for their protection.
Ford is a company built to manufacture exciting, safe and reliable vehicles at scale. There are processes, forms, sign-offs, engineering reviews and testing — all of which aren’t compatible with the startup environment we needed. When you follow all the processes and requirements prescribed, you just end up building the same thing. So after 12 weeks of validating our idea and securing the next round of funding, we quickly reached out to Connected [now Thoughtworks] to help us scale from a cool project on a Raspberry Pi to something we could launch on millions of vehicles.
“What role can Ford play to protect customers’ valuables inside their vehicles?” was the question Sam Harris, VP of Product at Canopy, faced. He had discovered the answer in audio threat detection, but in doing so, he also encountered a common characteristic of large enterprises that experience rapid, early-onset growth: a near-singular focus on scaling.
Activities
With our product thinking mindset and deep expertise in 0→1 early-stage product development, we were quick to integrate and begin building out the then Sentinel team (our project codename for confidentiality) from generalists to specialists as we set out to answer the question, “can we build this product at scale?”
First, we tackled key product risks upfront and continuously, giving us a better understanding of the current state of the product and assessing it against the Four Product Risks Framework:
Market desirability
- Is there a need for this product?
- What is the market size for this product?
Business viability
- Can we create a profitable business model for this product?
- Is the technology required available at the right cost?
- What organization is required to support this product in the market?
Product usability
- How do we create a product that’s easy to use and effective?
- Can we create accuracy levels that will lead to a positive User Experience?
Technical feasibility
- Is the technology envisioned capable of doing what we expect it to do?
- How can we create a security product in a low-energy environment?
To answer for scalability, we built a series of highfidelity prototypes, running two end-to-end pilots with real users, one in the US, and the other in the UK. As a result of these pilots, Ford was able to gain greater insight into the product that further guided development, including:
What does it take to create this physical product?
What steps are required to install the device on vehicles?
How does it perform on actual commercial vehicles?
Is it easy to use and does it provide the intended peace of mind?
Solution
Throughout the engagement Thoughtworks’ Product Thinking Playbook was relied upon to guide practitioners through various tactics and techniques ensuring team and product alignment. Notable of these include:
Conduct guided conversations with existing Ford pickup truck and van owners and other relevant individuals on the demand side to learn about their experiences, understanding, struggles, and feedback directly related to the area of investigation.
Collect qualitative information over a set period of time by having participants record entries about their everyday lives or about their experience with a product in either written, survey, or video form.
Detect early signals of change in core and peripheral environments using foresight frameworks to uncover new modes of thinking, provoke solutions from alternative perspectives, and develop strategies for the mid-to-long term.
Mapped the “pain relievers” and “gain creators” that your product delivers to the identified pains and gains of a Customer Profile Canvas. The Value Proposition Canvas summarizes the fit between the product and the jobs the customer is trying to do.
Conducted activities to generate possible product directions, concepts, and/or components. The resulting ideas and the common patterns between them became an inspiration for further concept development and validation.
From how we integrated to the education and enablement provided as the team grew, our approach was more than just trying to build a product — we helped them build a product company.
For each feature, articulate the problem or opportunity, sketch possible solutions, define the workflows, and create prototypes or production-ready designs. Sprints may also include user testing. Designers focus on one feature during each weekly sprint.
Build a technical prototype with just enough code to test out new technologies (e.g. algorithms, hardware, specific features, functional areas) to address technical feasibility risks, often related to performance, during product discovery.
Determine required hardware (sensors, circuits, and boards), components (such as libraries), and development environments (or frameworks) are available from a particular technology or for a particular usecase. Inspect the feature set and test capabilities; document and communicate findings.
Perform research and ideation activities to identify potential designs for a future-state application and system architectures and options for software solutions and frameworks that can be used to achieve the intended technical outcomes.
Identify and list all the known assumptions about the product concept and its intended user. Rank them in order of importance (based on how critical they are to the success of the product and/or their relative risk) and identify appropriate methods to validate or invalidate these assumptions one by one.
So why did they need to build a product company? As Sam said earlier, “Ford is a company built to manufacture exciting, safe and reliable vehicles at scale,” and referencing the diagram below puts them to the far right. The problem was where they needed to be, and more specifically, they needed help navigating the far left.
0→1 product building is very different from scaled product development. Whereas the scaled product development is more predictable in terms of inputs and expected outputs, allowing for greater efficiencies, 0→1 isn’t nearly as cut and dry. Instead, ambiguity, failure, and nonlinear thinking make for a better description of 0→1 product development, as outlined in Peter Thiel’s Zero to One.
If the squiggly line that’s meant to indicate just how nonlinear the nature of 0→1 product building isn’t clear, look at the corresponding numbers when 0→1 is viewed 0→0.5 and 0.5→1, respectively. But more than numbers, the differences between 0→0.5 and 0.5→1 in product development are as numerous as they are significant.
Outcomes
"How can Ford help protect the livelihoods of the people who have put their trust in them?"
That was the question originally asked, and one we've been able to help answer - with Canopy.
The success of the pilots and user insights did more than satisfy the executive team at Ford, eager to begin production. It caught the attention of security leader ADT, who, swayed by the compelling pilot results, decided to enter into a $100M joint venture with Ford to help protect the vehicles and livelihoods of their owners.
Ultimately, we wouldn’t have been able to form this partnership if it wasn’t for the pilot’s success. Because of them, we know with confidence what customers care about, what they want and how we can deliver it. The pilots proved the value of what we were doing, and without Connected [now Thoughtworks], there wouldn’t have been the pilots.