Finding product-market fit… again!

About six months into building a new product at Segment, an alarming question began to loom over our team, “Have we spent too much time on this with not enough to show for it?” 

When we first launched Segment, the answer to this question was much clearer. The beautiful thing about a startup’s journey to find product-market fit for the first time is that the company has a very well-defined amount of runway. When you have $X in your bank account and $Y burn per month, you can figure out exactly when your cash runs out. This kind of pressure regularly creates diamonds.

In established companies that already have found product-market fit, like Segment today, the runway calculation for a new product is much more ambiguous. There is no go-to amount to invest in R&D for a particular product, and it needs to hit a much higher revenue goal to make a meaningful contribution.

Luckily, the story I started with has a happy ending. This product turned into Personas, which now has strong product-market fit. But, admittedly, the approach we took when building this product had some flaws. If we ruthlessly prioritized our customer problems and solutions, instead of embarking on an infrastructure project too soon, we never would have let the runway question creep up on us. 

In this article, I’ll share learnings for product managers building new products within post-product-market fit startups. I’ll discuss what we learned building Personas and how we applied that knowledge to our next new product, Protocols. Together, just one year after launching Personas and six months after releasing Protocols, these new products total over $10M in ARR with a healthy mix between the two!

Don’t forget the M in MVP (Minimum Viable Product)

When I joined Segment three and a half years ago, our product helped companies route data from where it was generated to where it would be useful for their business. We provided one API to collect data from websites, mobile apps, and servers. With that single integration, we enabled companies to quickly turn on hundreds of new tools for growth marketing and analytics. 

We knew that we were in an excellent position to help our customers do more with their first-party data flowing through Segment. We believed we could help them tie together their data into a complete picture of each user that they could then use to personalize their product, marketing, and support. This change would transform our value proposition from saving engineering time to generating new revenue for businesses. In 2017, we decided to fund a project to tackle this vision. 

We started with research and found that customers had a ton of different ideas for what they wanted to do with the stitched-together user profiles. Some customers wanted to use profiles to build a “sidebar” for a customer support platform where an agent could see everything a user had done in order to answer his or her questions faster. Others wanted to build advanced personalization on their websites by calling the user profile programmatically. Still, others wanted to build “functions” for engineering teams to create on-the-fly computations over customer profiles for machine learning purposes.

With a product vision and general validation from customers, we started building an infrastructure that would support a broad range of use cases where we found user interest. We built a way to stitch together disparate IDs, host complete user profiles, and enable computations on top of the data. We were excited about the infrastructure we built, but about six months in, we started to worry about our runway. 

Because we hadn’t focused on a single “job to be done” or have mocks for a specific solution we expected to ship, we didn’t have any way to show customers the infrastructure work to gather feedback. We underestimated just how much engineering work was required for the infrastructure we imagined, and we lacked specificity on the exact problem we wanted to solve first for our customers. We realized we needed to make a significant change to our approach.

We did more research and forced ourselves to prioritize a single use case. From this second round of research, we discovered that the top use case for profile technology was personalization across all channels. The audience was growth marketers, and they needed a powerful user interface for centralizing audiences based on the most granular data possible to sync out to end channels. While I am proud of the product we built, I believe that if we had started with this level of focus, we could have gotten the product to market much faster. 

Here is a screen capture of Personas today.

From this point forward, we decided as a product team that we’d be much tighter on scoping truly minimal MVPs for all future projects.

Mocks before code: the most efficient path

Having learned from our experience building Personas, we took a very different approach to finding product-market fit for our next major product initiative focused on data governance. 

We noticed that there were a lot of inbound requests for additions to a feature we called “Schema.” Schema provides an overview of the data passing through Segment and basic controls for filtering out some of the data. While we could have continued to build the incremental improvements that customers requested, we didn’t expect to see a significant business impact from that approach. Based on the volume of these requests, and the purchasing power of the customers requesting them, we decided to take a step back and see how we could provide a more impactful solution to the underlying challenges our customers were facing.

Before we built anything, we assigned a team of one designer and one product manager to research the problem. We set up interviews with more than 25 customers who had submitted requests under “data governance,” which seemed like the overarching theme of their challenges. These interviews dug into the problems they were facing, how they’d prioritize solving these problems, the impact the issues had on their businesses, and their current solutions. 

We quickly noticed a pattern: customers were highly incentivized to avoid sending poor quality data to Segment. Messy data caused them to make bad product decisions, misfire marketing campaigns, and waste countless hours tracking down and cleansing bad data. Once we identified this problem, the product manager and designer pulled in a larger group, including engineering, marketing, and sales to brainstorm different approaches for how we could help our customers solve this. We came up with three potential directions that we took back to customers for feedback:

• Anomaly detection — When an event stops firing, automatically notify a customer.

• Transformations — When an event is sent incorrectly into Segment, allow the customer to fix it using the Segment UI.

• Automatic data verification — Provide a workflow to define a data schema and a set of tools to help verify and enforce that the events match the planned schema. (This later became Protocols.)

Our goal for the quarter was to get three screenshots of either emails or Slack messages with customers that showed real excitement around one of these features. Our stretch goal was to get a customer to tell us they’d be willing to pay for this feature once fully built out. The name of the game was prioritization. We wanted to identify which solution had the most customer pull, so we could build toward that job and that job only. 

Original low-fidelity mockups

Final product solution. Notice how similar they are!

We ended up prototyping janky versions of all three ideas. I initially thought anomaly detection was going to win out, but after running it for weeks, we still hadn’t found a situation where we saved a customer from ruin. It seemed like a “nice-to-have” feature. Transformations might have solved some real problems, but it effectively had no value for the type of data we could easily apply it to, and the cost to build transformations into all of our data types far exceeded the runway we had set for ourselves. 

We had one incredibly memorable customer visit that helped push us over the edge to focus on automatic data verification. Our designer, tech lead, and product manager flew to Los Angeles for an all-day onsite with one of our biggest enterprise customers. We watched their process for shipping a new release. 

They had a full team of more than five QA engineers that needed to test the data tracking across dozens of different mobile devices before they could release the change—almost a day’s worth of work. We realized how much better our original prototype could be if it automatically notified and enforced their preferred data spec, allowing them to quarantine or block bad data before it hit any of their production analytics or marketing services. 

This visit—and several additional interviews to test our new mocks with other customers—gave us great conviction that we were onto something. We continued to work hand-in-hand with customers to finalize the first version of the product and continue to refine it with customers today.

This story has another happy ending: Protocols had the fastest revenue ramp of any new product we have launched. Currently, it has a more natural go-to-market motion than past add-on products given we are selling to the same departments who buy our core product, Connections.

Principles for finding product-market fit again and again

As we continue our journey to find new product-market fit every year, we’ve embraced a few principles from our experience launching Personas and Protocols.

Ideas come from everywhere.

One of the keys to Protocols’ success was having engineering, product, and design collaborate from the very beginning. Design had some of the breakthrough ideas about the cheapest prototypes we could build. After hearing the pain directly from one customer, an engineer realized that to help customers uphold data quality, we had an opportunity to add a type-checking system in the code editor to prevent the errors from ever being introduced in the first place. This nugget turned into Typewriter, which is a favorite feature for engineers. In fact, the PM (traditionally the “finder” of new product-market fit) has described their role as “fading into the background, while the team generates all the great ideas.”

As we took the product to market, we also had our product and engineering teams work in incredibly close partnership with our go-to-market team. We received many of our later ideas about how to make the product more sellable from our partners in product marketing, sales ops, and sales engineering.

Prototype, iterate, and try not to code. 

While this is common advice for companies finding product-market fit the first time , we learned this lesson again—the hard way. The main reason that Protocols went to market so much faster than Personas was an incredible cycle and speed of prototypes and iterations. We were able to explore potential solutions with much more breadth, so by the time we took the product to General Availability, we had a tremendous amount of confidence that it would be a hit.

Choose your audience carefully.

One of the most important lessons about finding product-market fit again is that you need to deeply think about how your new product addition aligns with your existing customer base and sales motion. With Personas, we started to involve a new buyer (in our case, the Marketing team), which both expanded the market and also created go-to-market challenges in training the sales team and adapting our message. With Protocols, it was a much easier path since the product solved a huge pain-point for our core buyer. That said, there was more friction in packaging Protocols separately from Connections due to the close association. 

Understand your goals and runway.

With Personas, we had a vague idea of our runway, and we hadn’t stated the business goals clearly beforehand. Without agreeing on our intended investment upfront, we set off on an over-scoped MVP and then found ourselves doubting our progress about halfway through the project. A long infrastructure investment can be the right choice for carefully vetted and scoped projects, but we hadn’t been honest with ourselves about just how much runway we needed to pull this off. We also didn’t set any milestones along the way to prove customer value.

With Protocols, we fixed these mistakes. Having a very clear understanding of goals and runway helped us pick between the prototypes. One of them was going to take too long, the other wasn’t going to drive enough impact though it was a “nice-to-have.” Knowing we had six months to generate a new add-on product was a useful north star.

As a SaaS business, private and public investors measure us by our ability to increase net recurring revenue (NRR). This means we need to build new products to sell to our customer base and increase the value of our existing products. Therefore, finding product-market fit again and again is essential for us (and likely you) to get right. 

I encourage you to learn from our mistakes as you build out your own new products. These lessons make a lot of sense in theory, but they are often hard to implement in practice. It’s tempting to follow your gut, make tangible engineering progress as fast as possible (without customer validation), and avoid the tough questions that might lead you to kill a project.  

We’re not done learning yet. This year we have some exciting new privacy products launching. We’re running a similar process to how we ran Protocols to find product-market fit faster, and we will continue to improve on our process and share what we’ve learned along the way. 

Want to iterate together with us? We’re hiring.