When & Why it Makes Sense to Deliver a Minimum Sellable Product, Not a Minimum Viable Product
Jonathan Marks and Alex Wirth were in their junior year of college when they first had the idea for Quorum. “I was working in a computational biochemistry lab and taking computer science classes,” Marks remembers. “Alex was working on the Hill, running into a lot of roadblocks while promoting the passage of a couple of resolutions related to a youth advocacy project he was working on.”
As the two friends discussed the challenges Wirth was facing, they realized there was a real need for a tool that would help organizations grasp what was happening around a piece of legislation. “Organizations needed help understanding what was going on, both legislatively and also just related to what various people were talking about on Twitter, Facebook, or YouTube, in press releases, and on the floor. In addition, people and organizations needed a way to identify actionable insights about legislators based on who they know and which issues they care about.”
From those initial conversations, Quorum developed to be a critically valuable tool for people whose job it is to influence the legislative process. From companies and nonprofits to advocates, startups, and members of Congress, people from a variety of sectors use this comprehensive software to track legislation and dialogue, target particular individuals as key players and identify potential allies.
How the co-founding team got from initial concept to flourishing SaaS company is an interesting story about how to create, instead of a minimum viable product (MVP), a minimum sellable product (MSP).
Breaking the Lean Startup Model
“We broke the lean startup model almost by accident,” says Marks. “Originally, we were trying to follow the rules by delivering a very targeted product that did one thing: identify the relationships between legislators and provide information about which legislators know each other, how well they know each other, who is central within a network, and how you can move from one group of people to another in an intelligent way.” This early version of the product was a targeted, analysis-focused computational product; but it was soon going to evolve into something completely different and much more complex.
“Alex took that early alpha to DC and put it in front of thirty people who represented our target audience,” Marks says. “And, he heard different things from every single person.” Over the course of that initial alpha review period, people provided feedback about other functions and features that they’d like to see, including things like the ability to see who is talking about whom, the ability to see the input related to bills and votes so it would be easier to understand how the product delivered certain conclusions, and the ability to generate reports that would help a user demonstrate to superiors the logic behind a particular decision.
“Over the course of just those first thirty meetings, we collected enough feedback and ideas that it ended up taking us two years to build it all,” says Marks. “And the reason we decided to take that time was that right from the start with the initial product, there was so much demand for other things. That’s what got us thinking about the idea of a MSP, or minimum sellable product, instead of a minimum viable product.”
The basic idea was to figure out what people would be willing to pay for and then build that right out of the gate instead of launching with a less robust, freemium or low-cost product. “In the end, we have to generate revenue to survive,” Marks says matter of factly. “So, from the very beginning, we pursued revenue wherever we could find it, and it just happened that the path led us to build out a very comprehensive set of tools. That breadth of functionalities then became part of our value proposition.”
Identifying the “Real” Problem
The first step in developing the Quorum MSP was for Marks and Wirth to drill down into the “real” problem faced by their target audience. They started this process focused on one piece of the larger problem, but eventually found their way to the more fundamental need.
“The differentiator between our approach and a more typical approach, is that the typical approach is to focus on just one problem,” explains Marks. “For example, one of the problems we were aware of was how hard it was to send bulk emails to staffers on the Hill and keep track of their responses in a personalized way that doesn’t require repeating the same steps over and over again.”
“The typical MVP approach would be to build a product that solved just that problem and solved it, to the best of your ability, perfectly,” says Marks. And, in fact, there were several companies in the market who were launching those kinds of specialized products.
Instead of starting and stopping with that problem, Marks and Wirth took a closer look at the problem in order to get at the root of the issue. “Thinking the problem through, we realized that for our clients to be able to email the Hill, they needed a database about staffers that was not only up to date, but also enabled functionality like building reports and tracking relationships and interactions,” says Marks. “Our clients needed to do more than just email staffers, they needed to be able to build institutional knowledge about their history and relationship with each particular staffer, and then be able to store additional information so that everyone in the organization can see it.”
In the end, by thinking laterally, the Quorum team realized that they didn’t need an email tool – they needed a flexible, accessible, and fully functional tool to analyze data and relationships. That was the real — much broader and more complex — need that people would be willing to pay for.
Building on a Broader Foundation
“The minute we started building all the other things people had requested, we got into a position where our product’s functionality was crossing over with some of the other products in the space,” Marks says. “There were some things we did that other products didn’t do, but there were also things other products provided that we didn’t.”
This created an additional challenge for Quorum because buyers were already having to use multiple products to meet their needs, and their budget constraints weren’t likely to accommodate an additional purchase. “In this market, people traditionally buy separate products for federal and state,” explains Marks. “They also might have one product to communicate with Congress, another to track relationships, another to message supporters, and so on. It’s very fragmented.” In the beginning, Quorum wasn’t good enough to replace any of these existing solutions, but Marks and Wirth were quickly learning what they would need to build to set their product apart so that buyers could justify the purchase.
“Yes, they needed more access to data and a better interface that would allow them to search, slice and dice, and analyze that data,” Marks says. “But we came to realize that, more than that, what they really needed was a product that would do all of these things in one tool. Having to push information between multiple systems and learn different interfaces for each task presented a cognitive load and a barrier that kept people from doing their job really well.”
To deliver this all-in-one, broad product, Marks and Wirth needed to take a customized approach to the build. “We built our own search engine inside of our database that was powerful and fast enough to efficiently search for bills, documents, and giant data sets,” says Marks. “Because we were able to invest in that kind of central infrastructure and centralize our technology, we’ve been able to enhance the quality and usability and speed of the entire system and all the products. It has also enabled us to iterate more rapidly.”
Another key philosophy that the team embraced was moving away from building in silos. “The reason customers were having to use so many different tools to address their needs is that companies were building in silos,” explains Marks. “A company would build one tool in one silo so that it did everything that one tool needed. Then they would build a second tool in a second silo that would perform a tangentially related task.”
Instead of isolating feature sets within distinct silos, the Quorum team tackled a wide range of features all at once. “Even after just three months of development, we were trying to do legislative tracking, dialogue tracking, and analysis features along with building out productivity tools,” says Marks. “At a very early stage, the list of features that we had built to support was very large and very broad, and then we continued to expand laterally within each product.”
Knowing When Broad and Shallow Beats Narrow and Deep
Launching with a broad and shallow product isn’t for everyone, but in the right circumstance, it’s a powerful strategy. It’s the best fit when your customers need a solution that offers broad functionality that’s capable of addressing a multitude of use cases. “Our target buyers had many things in common,” says Marks, “But one of the most important was that lots of them had multiple products with overlapping functionality. There was significant customer confusion over which products were the right choice to solve various problems.”
“In our case, we still launched early because we needed the revenue and feedback, just like everybody else,” says Marks. “But instead of launching a narrow but deep product, we launched a broad but shallow product and over time have built it out so that the depth is now greater than or equal to everything else on the market.”
Leaders from Twilio, IBM, SurveyMonkey and more share their best tips.
Travis Jamison shares some of the lessons he’s learned through all of the ups and downs, wins and losses of being an early-stage startup founder.