B2B MVP Pitfalls: When Large Customers Quietly Complete Your Product
And why you won't discover the missing pieces until everyone else says no
By Kenny · Quick Answer: When building a B2B MVP with a large company, startups risk letting that customer silently complete critical parts of the product — leaving gaps you won’t discover until other prospects say no. As product managers, we need to explicitly map every piece of the whole product, including what the customer handles internally. The best defense is having at least two to five early customers so their competing requirements reveal which features are universally needed versus idiosyncratic to one company.
(This is a guest post by Sean Murphy, who coaches early stage technology firms for B2B MVP. You can find Sean on Twitter, LinkedIn or on his blog.) Startups have to take care to extract as much as they can of a larger firm’s understanding of a problem. Without this a startup can have “missing pieces” in their solution. Even when the larger company lays out the full problem and what’s needed to solve it, a startup may mistakenly decide to address a subset of the problem. If the larger company supplies the residual pieces without complaint, the startup is lulled into a false sense of security until they have tried to sell their solution to other companies and have been turned down several times. I have personally experienced this several times from both sides of the table, here are a couple examples of what this looked like for startups. 
If you’d like to cut to the chase, you can download our B2B MVP (Minimum Viable Products) checklist here: Download That’s Your Problem Mr. Customer… Actually All of Your Customers Have This Problem One, when I was working at Monolithic Memories we worked with a startup company, Silver-Lisco, to develop a timing-driven layout application where in addition to worrying about whether or not a ASIC could be routed, we could also provide timing budgets for the nets, and those timing budgets would drive the placement of the components to get not just 100% routability but also better timing for the key aspects of the circuit that drove performance. We spent many months working with Silver-Lisco specing out different approaches. We tried several approaches to weighting the nets. We ultimately leveraged a model from operations research where you actually applied two weights to every net. We took this approach because we discovered that by optimizing the critical nets too much we were making more normal nets longer: this added wire length added to chip routability problems and in some cases actually pulled a normal net long enough to make what had been assessed as a sub-critical path become critical. Also shortening the critical too far below their timing threshold didn’t meaningfully add to margin. Along the way there were several aspects of that problem that had to be solved: you had to estimate the net lengths, determine which were critical for timing, and calculate the weights and thresholds to be applied to each net, and the placement and routing software had to use that information effectively to generate the final layout. We settled on a demark where we would supply a file with the weights and thresholds for each net and wrote additional software to make that happen. This supplemental tool would analyze the circuit and come back with a fully generated file of weights. What the Silver-Lisco people didn’t understand until they went to the next customer was that when they said they had a timing-driven layout solution they had no way to calculate or generate those weights, and so they didn’t really have a solution. Monolithic Memory was just fine because we had our piece of the technology but we were not going to transfer to them what we developed so that they could give it to our competitors. We had not set out to create a blocker but the Silvar-Lisco team had set the demark before talking to other prospects and they ended up losing the better part of a year playing catch up. Don’t Worry; We Can Take Care of That B2B MVP Without Your Help… It’s a Shame None of Your Other Customers Can Figure it Out I saw the same thing happen when I was working at MMC Networks on B2B MVP. We developed and sold these complex network processors and in the beginning our only customer was Cisco. We developed the silicon and a specialized compiler for them. However, Cisco did the programming of the chips and there were certain aspects of writing the code where Cisco said, “Don’t worry about that, we can care of that.” Then we went to IBM and several other potential customers and as they started to use the chips in their product they would ask, “How do you make these modes work?” We realized that Cisco had written extensions to the compiler to handle certain aspects the devices. And our other customers couldn’t take advantage of those features. It wasn’t because we hadn’t put them in the product. It was because we hadn’t actually developed the whole product. Where Is The Transmission That Goes With This Engine? One more example where we inadvertently let a large corporate customer in the oil and gas space complete the product and create a blocker for our offering. Our client had developed a Big Data solution for managing complex and time varying scientific data collected on natural phenomenon. One use case is for subsurface geological structures: they exhibit discontinuities that you don’t find in manufactured or hand crafted items and being buried under a few hundred feet to a few miles of ocean and/or earth are not easily inspected. Typically you have to make assumptions about their composition and structure and then iterate based on how well that fits your data. The company developed a interactive hypothesis capture visualization tool that allowed experienced geologists to start from a rough guess and then rapidly converge on a model of the subsurface structures consistent with all of the data. Our client took care of the complex data management and parallel data analysis in the back end. Because the oil and gas company had developed the interface it was very difficult to demo or explain succinctly what we could do for other firms interested in solving similar problems. Sometimes You Take On Too Much Now it also goes the other way. Sometimes the larger company will say, “We have all these requirements,” and it turns out that actually the real solution only needs a few key ones. In that case, a large company will specify requirements A through F and it turns out that to actually get a basic product into the market that works for most companies, you only need features A, B and C, and that E and F are actually unique to a large company. If you are implementing things that are idiosyncratic just to them, it is important that you understand that so that you implement just the right mix of features. The other way immunize yourself from that, is to not stop when you have your first customer, but to actually continue to look for several other early customers so that you’ve got three to five, at least two, so you’re looking at a mix of requirements. That way you can let those customers argue with each other. If you only have one big customer and you’re letting them dictate your feature set, you’re at much higher risk of doing things that are idiosyncratic and it’s much harder to push back because they’re the experts. You’ve got nobody else to argue with them. 
It’s Not Always Intentional But It’s Hard to Fix I don’t think Cisco or Monolithic Memories or the oil and gas firm set out to create a blocker, but these three startups lost sight of the whole product. I think that’s something you’ve really got to pay a lot of attention to when you’re working with a large company. It’s very good to work with larger firms and it’s very good to get their perspective on the problem, but you got to make sure that you’re capturing the whole product. Want to avoid common pitfalls when building your B2B MVP- Minimum Viable Solution? You can download a checklist here: Download
Frequently Asked Questions
What is a B2B MVP and why is it risky to build one with a single large customer?
A B2B MVP is a minimum viable product designed for business-to-business markets. The risk of building one with a single large customer is that the customer may quietly fill in gaps in your solution themselves — handling critical pieces you don’t even realize are missing. This leaves you with an incomplete product that fails when you try to sell it to other companies.
How do large companies accidentally create blockers for startup products?
Large companies often say “don’t worry, we’ll handle that” for parts of the solution they can solve internally. As we saw with Cisco and MMC Networks, the customer built compiler extensions that completed the product — but those extensions weren’t available to other customers. The startup didn’t realize key functionality was missing from their offering until prospects couldn’t use it.
How many early customers should a B2B startup have to avoid building the wrong features?
Startups should aim for at least two, ideally three to five early customers. Having multiple customers lets their requirements argue with each other, helping you distinguish between features that are universally needed and those that are idiosyncratic to one company. With only one customer dictating your feature set, it’s much harder to push back because they’re the experts and you have no counterpoint.
What happens when a startup builds too many features based on one enterprise customer’s requirements?
Sometimes a large company specifies requirements A through F, but only A, B, and C are needed for a product that works for most of the market. Features E and F may be unique to that one company. If we implement everything without understanding which requirements are idiosyncratic, we waste time building features that don’t help us reach the broader market.
How can startups make sure they’re capturing the “whole product” in B2B?
Startups need to explicitly map out every piece required for a complete solution — including pieces the customer is handling themselves. As the Silver-Lisco case showed, the startup didn’t realize they lacked the ability to generate critical weight files because Monolithic Memories handled that internally. Continuously validating your product’s completeness with additional prospects, not just your first customer, is essential to avoiding this trap.
Comments
Loading comments…
Leave a comment