Expanding the Product

Hansen Liang
Sep 5, 2020 · 7 min read
Photo by Diana Parkhouse on Unsplash

Prior to joining Klaviyo, I started my career at Lutron, where we designed and built smart building systems: Imagine pulling up to your dream house in your dream car — we made the lights fade on with your presence, the shades roll up, and the house come to life. Such systems required specialized software to design, which was the product I worked on. I’d like to share some lessons I learned in my first years working in Product.

As a fresh engineer-turned Product Manager, my view of the product was shaped by those around me: the customers, the engineers, the designers, and the business leaders. Everyone had endless lists of demands and wishes, and I kept busy learning the basics of defining, building, and releasing features.

It was fun to work through challenging customer problems and come up with clever and delightful solutions. However, as time went on, I couldn’t help but wonder where we were taking our product, the best-in-class design studio for commercial IoT systems. Our customers raved about our software as a key differentiator in our whole product experience. We were ahead of our competition, which meant that we couldn’t simply look to others and imitate.

A Backlog-Driven Roadmap

We all have endless lists of features and bugs.

For a while, our roadmap was driven by our stakeholder-made backlog. We had lists of prioritized features from each of the business units we supported. We divided our efforts based on per-stakeholder budgets — department A gets 70% of our bandwidth, department B gets 10%, and so on. We let the powerful stakeholders negotiate their shares. While we did the legwork to conduct the user research and create the JIRA tickets, these stakeholders more or less defined their chunks of the roadmap, and we simply stitched them together so that we were delivering something nice for every stakeholder in each release.

This model worked well for some people. The stakeholders were happy because they pretty much dictated what they got in each release. The engineers were happy because there was great visibility into what came next. Overall, there was a sense of predictability and complacency, which to many was preferable to ambition and chaos.

But complacency is dangerous. I knew that this mode of working could go on for a long time because it was comfortable. I also knew that incrementally polishing our product wasn’t going to keep us the industry leader, let alone set us up for breakthroughs. It was only a matter of time before someone disrupted us.

We needed to expand our product beyond iterating within its box.

Expanding Horizontally

The first thing we did was to take our existing advantage into an adjacent market. Our tool already excelled at designing complex IoT systems, and our company had an unfair advantage over most competitors: we offered Total Light Management — not only did we control artificial light, we also automated daylight management via motorized shades and networked sensors. After all, the human need is to control light and ambiance, regardless of the source of emission.

Traditionally, commercial lighting and shading solutions were 2 separate verticals. Differences in the whole process from specification to buying to installation dictated that there were 2 distinct groups of decision makers often buying from 2 different manufacturers. On the shading side, people were primarily relying on generic tools like Excel and PDF editors to do their job, which can be so cumbersome and error-prone that unless there was a high probability of winning, people didn’t even bother putting in a quote. We set out to change that, and our software was a key tool to enable this change.

Our product was made to automate the lighting system design process, and was not made to support shading. When we analyzed the architecture of our product against the requirements of the new market, it was clear that we had a momentous opportunity:

The needs of the 2 markets heavily overlapped (after all, they were working on the same buildings and underlying systems) even though they were often separate businesses. Our software was great at handling the fundamental needs of building design, and it was a matter of adding support for new product components and adapting existing features.

Of course, the actual planning and execution held far more lessons, but the overall strategy paid off. We not only enabled existing users to sell what was once two separate solutions in one package (which was a compelling edge, saving money and time for all parties involved), but also helped the company transform our sales channels thanks to the easy-to-use automations that democratized the design of shading systems. It was pretty cool to see new businesses and careers made possible by our product.

Expanding Vertically

As time went on and I had the opportunity to learn more deeply about our customers through many on-site visits (which I strongly argue is the best and most valuable way to learn from customers), I started to think beyond adapting our tools to serve previously underserved industries and audiences.

When we examined our customer journey maps, we noticed that many of our users were executing repetitive tasks because there were distinct stages, stakeholders, and needs in their journey. For each stage, they preferred specific tools to optimize their workflow: they’d rather do duplicate work later once the job is won than invest time early on when the risks are too great. We mapped out their software stack over the course of their job cycle.

An oversimplified view of our users’ tech stack

Each of our customers figured out their own stack. Some learned the tricks from a previous job, some went to trainings and industry events, some experimented endlessly to hack together unique automations. By visiting and interviewing many users, a common pattern emerged along with a set of JTBDs (jobs to be done). Since construction, like many other disciplines, is fundamentally an iterative process going from coarse concepts to detailed implementations, this scattered approach was inherently wasteful. Our customers were forced to trade off long-term efficiency for short-term risk aversion. Lots of work was done with disconnected, proprietary tools (if I had a dollar for each time I saw a complicated Excel template…), and most of the work ended up thrown away because there was no simple path to transfer existing work into the next tool in the process.

This was an opportunity for us to redefine their stack.

An oversimplified view of our customers’ tech stack after our update

We used the overall customer journey as our guide, not just the parts that touched our product. We looked at the whole stack, and asked ourselves how we could make working within our ecosystem even easier than working with their current shortcut tools of choice.

The result was a one-stop solution for quoting, designing, and programming large-scale commercial IoT systems. We dramatically reduced the time and knowledge required to adopt our tools, and changed the software stack for many of our customers. In fact, our tool did so well that some people started “stealing” it to create competitor solutions — because even with the overhead of translating system designs, our product was still far superior than the alternatives. While that was a whole separate issue, it put a smile on our faces. We knew we had done something right.

Along the way, we also came up with some pretty radical ideas around rearchitecting our systems and completely redefining the logic and models behind our software, which opened the door to a whole new paradigm for automated design solutions. But that is a story for another day.

A Roadmap-Driven Backlog

No longer were we simply executing on the wishlists of our stakeholders who divvied up our bandwidth; We listened to our customers and strategically set our roadmap to deliver more impact. Our vision drove the backlog, not the other way around. This is part of our jobs as PMs. After all, “it’s not the customer’s job to know what they want.”

Setting the roadmap is part science, part art. The above is just a simple mental model I used to expand my product and make quantum leaps in the impact we delivered.

Look horizontally, and you’ll see “adjacent” verticals where your product’s unique advantages can translate nicely and enable something that people in those markets had never seen.

Look vertically, and you’ll discover opportunities to simplify your customers’ workflows and deliver compelling value beyond the original scope of your product.


Product @ Klaviyo


Follow along Klaviyo Product Team’s journey to build impactful, “whole product” experiences that empower our users and help businesses grow.

Hansen Liang

Written by

Product manager, designer. Innovate with vision, so the future is no accident.


Follow along Klaviyo Product Team’s journey to build impactful, “whole product” experiences that empower our users and help businesses grow.

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store