Disclaimer: This should not be a blog post. It should likely be a trilogy of chapter books complete with glossaries and appendices.
But I don't have time to write that, and it's likely you don't have time to read it. Thus, with the time we do have, I'll walk you through what it's like to design a product that never before existed on the market.
Where do we start?
Understanding the use cases is arguably the most important part of developing a new product. After all, you could build the wicked-cool technology, but if no one uses it, what good is that?
Talk to the stakeholders, find the pain points
Before diving into building a solution, we need to understand and empathize with the problem itself. To do that, we talk to our potential customers, explore the tools they currently use, ask about the pain points they have, and gather feedback and insights that can help us during the designing phase.
After interviewing managers, business owners, and team members, we boiled down some key road blocks for these stakeholders:
- The product (automated security software) was way too expensive.
- These software tools were too hard to use, and required extensive training for their teams.
- These products had a tendency to be malfunctioned, costing them more money, time, and headaches.
In the process of interviewing and researching, you find these golden nuggets of information. We refer to them as ah-ha moments. In this case, we found a user that signed a contract with a similar software platform, but could only use half the features since the full package was too expensive.
Research, research, and more research
Before we start building, we need to understand what our competitive advantage might be. What can we provide to customers that a) solves their major pain points and b) is so amazing that they actually switch from their old service to ours?
There is a balance between dreaming big and setting realistic goals. As with any product team, we want to build the product that solves all our users' pain points. But that isn't realistic. This research phase compels us to understand what is lacking in the current product offering, and how we can fill that gap with our solution.
In this case, we set out to address three key pain points in automated security software:
- Completing the circle: Completing the circle: an event notification pops up in your phone that the camera has spotted someone suspicious, but what happens after that? Even if you have subscribed to services that dispatch an officer on your behalf (lucky you!), what happens after that?
- Affordability: rather than paying thousands each year, how can we make this software accessible to businesses small and large?
- Reliability: no crashes, no downtime, no headaches.
This is what happens when the software that you're overpaying for crashes during peak hours.
Document your findings: why this, why now, why us?
Conducting your research is half the battle, it is then critical to collect and synthesize this information and involve your internal stakeholders in the process. Once the research phase was completed, we brought in our engineering and marketing teams to discuss and openly raise questions.
This process is extremely valuable to the team and determines the success of the end product. During these open discussions, we get a variety of perspectives and analyses of the problem, while also ensuring everyone is on-board with our vision and direction. It's not always smooth sailing either, these conversations demand heated debates and brainstorming.
The wrap-up
What you just witnessed was the pre-building phase of our design process. Before a wireframe is drafted, before a single line of code is typed, we sink our teeth into the problem at hand. It’s no small feat, but a very necessary step to know your battleground.
In our next blog post, we'll walk through the creation phase and dissect what it means to make a brand-new product.
