(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:
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:
