Back to resources

Building a Functionality-Rich Product From Scratch

Managing Expectations

31 August, 2021

Mary Lauran Hall
Mary Lauran Hall

Senior Product Manager at Kevel

MaryLauran Hall, Senior Product Manager at Kevel, describes how to approach building a brand new product with multiple functionalities by starting small and expanding piece by piece.


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.

Discover Plato

Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader

Related stories

Scaling a Team in Two Parts: The Product and Manager

2 August

Viswa Mani Kiran Peddinti, Sr Engineering Manager at Instacart, walks through his experience scaling a team, product and his skills as a leader.

Managing Expectations
Scaling Team
Viswa Mani Kiran Peddinti

Viswa Mani Kiran Peddinti

Sr Engineering Manager at Instacart

How to Organize, Manage, and Grow Your Team

12 July

Vineet Puranik, Senior Engineering Manager at DocuSign, discusses the impact of roadmaps, organization, and proper management for your teams to procure growth.

Managing Expectations
Vineet Puranik

Vineet Puranik

Senior Engineering Manager at DocuSign

How to Navigate Your Manager Role at a New Company

1 July

Saikrishna Desaraju, Engineering Manager at Marks & Spencer, draws from his personal experience to advise new managers on thriving in their roles.

Managing Up
Managing Expectations
New Manager Of Manager
Changing Company
Saikrishna Desaraju

Saikrishna Desaraju

Engineering Manager at Marks and Spencer

How Product Management Chose Me

23 June

My accidental journey into product management

Personal Growth
New PM
Career Path
Michael Castro

Michael Castro

Sr. Manager, Product Management at Capital One

How Product Marketing Can (and Should) Help Product Development

20 June

Pavel Safarik, Head of Product at ROI Hunter, discusses the frequently overlooked role of product marketing in getting high user adoption rates for your product.

Goal Setting
Product Team
Different Skillsets
Cross-Functional Collaboration
Pavel Safarik

Pavel Safarik

Head of Product at ROI Hunter