Building a Functionality-Rich Product From Scratch

Problem

Some years ago, I was helping build an energy management tool that people in charge of commercial buildings would use to assess whether their HVAC (Heating, Ventilation, and Air Conditioning) systems were working as expected across a portfolio of properties. Our tool would help them compare, for example, the set and actual temperature in a particular zone within a building, which would allow them to identify a potential problem in a timely manner.

The plan was for the tool to serve a portfolio of commercial customers, who in turn controlled a large number of buildings that themselves had many HVAC zones. Our initial customer discovery showed that we had a compelling idea to address a massive problem in the market, but at that moment, we still didn’t have much understanding of how to build an app that could solve it. With validation in place such that we were confident that it would be valuable to customers if we were to build it, we faced the challenge of the actual engineering work to build it.

Actions taken

To make this problem manageable, we decided to strip down the problem to the simplest possible use case that would still capture the app’s rich functionality: we focused first on a single customer within a single building and a single HVAC zone. We worked on making the entire user journey work for just this rudimentary use case: a commercial building manager could log in, see their one building, and see their HVAC performance within one zone in that building. Yet, we were solving the problem for one very narrow strip.

This approach enabled us to answer a good deal of complicated technical questions without having to deep dive into a broader scale of complexity at the same time. We learned so much by pursuing this approach, from integrating with an IoT data provider to building the back-end infrastructure to store and process that data, to establishing a front-end framework and addressing authentication. We were also able to gather customer feedback along the way. Then, once we had built for this simple user case, we expanded two HVAC systems at one location, then more locations, then more customers.

Why did we decide to start small? Whenever you are approaching a new build, there are many technical questions and risks. It makes the problem more technically intimidating to also solve for large numbers or multiple use cases at the same time. But if you narrow the problem down to a narrow scope that still forces the team to figure out the key steps in the experience, you can address those questions and learn without being distracted by unnecessary complexity. Of course, you want to do all this while making sure you’re building something that adds value to customers and contributes to key business goals. Being able to course-correct, if you need to, is much easier on a smaller scale.

Lessons learned

• When building big, narrow your focus and start small. That said, make sure you are hitting all the different layers of the customer experience but still tackling a very narrow vertical slice. Consider how you can capture a vertical slice of the product experience to start, rather than just base-level functionality.
• Be ruthless about what you eliminate. If your initial goal is to de-risk the idea from a technical perspective, you might even get rid of or delay things that are essential for customer usage! Know what risks you’re tackling and choose accordingly.
• Be strategic about what you will cut out. Have those uncomfortable conversations with your team and leadership based on customer research. If you try to build everything from the get-go, you are much more likely to fail. Starting small makes the goal more achievable.
• If unsure what to start with, consider your product pyramid. The base layer should include basic functionality functions such as security and access, the middle layer nice-to-have functions that include functionalities that customers need or want, and then on the top are delighters — things that will make your product lovable. Ideally, your strip should be a narrow strip of those, which will guide you on what to cut out and how to reduce scope.