Our first ProductHack looked at logins and the benefits of the “build one, test the rest” approach. Next up in the series, we’re going to explore a hack that’s a little more sales oriented…
Don’t Build It, Sell It
We work with a lot of entrepreneurs, and so a big part of our customer’s success is to help them sell their solutions. And even though it sounds inversely proportional to how we make money, our advice usually starts with “Don’t build it, sell it.” Here’s why…
Selling software—or anything for that matter—requires tools. At one end of the spectrum, a rockstar software salesperson can walk into a pitch meeting with nothing other than themselves and still close a deal. At the other end of the spectrum, another salesperson will need everything (i.e. a minimum viable product, or MVP) before they can convince prospective customers to close a deal.
Given the “Don’t build it, sell it” mindset, you should strive to close a deal with as close to nothing as possible. This minimizes your risk of building something that a customer won’t end up buying anyway (i.e., if you built the wrong thing). It also allows you to get some up-front cash to finance the product development.
So let’s look at each level of the spectrum, starting with the the most efficient…
Nothing
As briefly discussed above, there are salespeople that can land the seven-figure deal with nothing but his or her vision and contagious conviction. They are rockstars. Unicorns, really. But they do exist. They deeply understand the customer’s business and the problem at hand. They have the customer’s trust and are able to effectively communicate the solution. Moreover, they’re able to crystallize how this proposed solution will directly impact the customer’s bottom line. This level requires minimal risk outlay as well as an equally visionary customer. It’s the epitome of “Don’t build it, sell it.” So when you find a unicorn, hang on to it and guard it with your life.
Deck
One step up is the deck. Everyone’s familiar with it. A deck does a good job of visually communicating the pitch. A deck also gives the audience something to physically reference. From the seller perspective, there’s little risk in spending time on a deck. In fact, it’s often expected. But for a more technical audience, a deck isn’t likely to convince and it will often leave more questions than answers. Plus, without the salesperson there to explain, most decks fall short on context. So with a deck, you build a little before selling, but not too much.
Wireframes
Wireframes are a great way of honestly communicating that a solution is in the design phase, but not built yet. Obviously there’s an investment required to create these, it shows the customer that you’re serious, but is that enough? If the answer is yes, wireframing was time well spent. If the answer is no, you probably should’ve just gone with the deck.
Interactive Prototype
Next is the interactive prototype. Think of this as a shell of the product. It works, it’s clickable, but it isn’t a fully interactive environment with a database backend. Nor is it coded. Instead, it will only feature a few use cases or workflows. It might be pixel perfect, or it might use a sketch-like interface. For example, we’ll build an interactive prototype of an iPhone app in Axure. The thing works in a few different ways—it’s just not on an actual app from the App Store. And it’s likely functioning only on sample data. Again, as we move up the scale, increasing the effort outlay needs to be directly correlated to the likelihood of the deal closing.
Coded Prototype
The definitions of “Coded Prototype” can vary widely. Is it completely designed? Is it front-end code only? Does it have a database backend? In rare cases do you want to use a coded prototype as a selling tool, and I typically only recommend it if a prospective customer requires it. If that’s the case, you should be really clear exactly what a prototype means since the shades of gray can make or break a project. I’ve seen coded prototypes used as a method to split stages of development such that additional vendors are invited to bid after the coded prototype is completed. Again, this is largely customer dependent.
Minimum Viable Product (MVP)
And at the far end of the spectrum is the situation in which a MVP is required. This typically requires the most risk and up-front cost for the product entrepreneur. You see it in situations where the idea—or the deck or even a coded prototype—just won’t cut it. B2C products or ecom marketplaces are good examples as they require a fully built out back-end database in order to “work.” Obviously, this tool requires the most time, labor, cost, and risk. But again, if all signs point to it being required to get a deal done, then it’s a worthwhile investment.
So how do you ultimately determine what tools are required for a given pitch? A lot of it depends on you, but it also depends on your choice of prospective customer. It might take a lot of work to convince a prospective customer to buy without proof And it’s an artform for a salesperson to deal with the myriad of potential objections:
- “We only buy from established leaders in the Gartner Magic Quadrant.”
- “I need to see a demo before I can recommend this to my boss.”
- “Come back when you can give us some customer references similar to us.”
Building a digital product?
You need to choose your prospective customers carefully, and you probably need to walk away from those that demand you to build the full product before proceeding. In The Lean Startup, Eric Ries uses the phrase “Visionary Customers” to describe the type of customer that you can be transparent with about the state of your product, and is willing to work with you on an MVP that is far less than perfect. Taking this a step further, you might be able to get a customer to pay for the wireframe or prototypes if that customer is the right customer and you can successfully pitch it.
