Startups Working with Large Companies & Minimum Viable Products

(This is a guest post by Sean Murphy, who coaches early stage technology firms. You can find Sean on TwitterLinkedIn 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.

minimum viable products - illustration - missing puzzle piece

If you’d like to cut to the chase, you can download our B2B 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 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. 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.

minimum viable products - illustration - too many features

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 Minimum Viable Solution? You can download a checklist here:


Discussion (4 comments)

  1. Michael Salerno says:

    These are great examples why attention to the whole product is required when building technology for a market, versus a single customer. The role of product management when properly filled is the “insurance” that prevents these scenarios from happening. I have also seen these scenarios play out in Joint Venture co-development initiatives at large companies, which managed the same way generates the same results. If you develop technology for a market, it is a good idea to consult a professional.

  2. Nis Frome says:

    Something I’ve learned while working at a startup and selling to large companies is that the value proposition is a much smaller component of the sale to them than other aspects (I know what I’m about to say has more to do with sales than product, but when you’re at a startup you wear multiple hats so it’s relevant). Large companies have many other factors to consider such as:

    – Has this been socially validated / vetted by other companies?
    – Am I even expected to solve this challenge?
    – Am I more likely to get promoted if I solve this challenge?
    – Will solving this challenge great more work for me that I wouldn’t have to do otherwise?

    I find that when selling to enterprise, you need to figure out what makes the user ‘tick’ and sell to that point (often it’s the likelihood of a promotion), not just to the value proposition. Anyway, just another point to consider in addition to the excellent ones made above.

  3. DanialAsaxy says:

    Hi, I think your website might be having browser compatibility issues. When I look at your website in Chrome, it looks fine but when opening in Internet Explorer, it has some overlapping. I just wanted to give you a quick heads up! Other then that, fantastic blog!

  4. Pingback: Corporate Lean Anti-Patterns - 5 Minute Video by @TriKro

  5. UteBruni99 says:

    It’s awesome to go to see this web site and reading the views of all colleagues about this paragraph, while I am also zealous of getting know-how.

  6. Pingback: SKMurphy, Inc. Mark Williamson, CTO of Hanzo Archives, on Validating Startup Ideas

Got something to say?

This site uses Akismet to reduce spam. Learn how your comment data is processed.