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.
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?
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:
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.
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:
This is what happens when the software that you're overpaying for crashes during peak hours.
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.
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.