The Augmented Product

By history, I was an Offering Manager. Think of that as a "full-stack product manager," encompassing a broader view (and purview) than typical product management. That experience offers some insights that I share here. (Please note: my experience is exclusively B2B – some adaptation for B2C is probably warranted and is left as an exercise for the reader.) Entrepreneurs ignore this broader view at their peril. There is some tough love in this article - I make no apologies.

We start with a simple insight: buyers buy value to them. (Alternatively, "Buyers buy solutions to problems that limit the value they can generate.") Obvious, right? And yet, many entrepreneurs assume that what they are building and selling is a "solution," and then are surprised that it fails in the market.[1] Why is that? Because - and I can't say this enough - it's not about what you are selling, it's what customers are buying. And what they are buying is an aggregate that creates, and lets them access, value to them.

An aggregate? To deliver value, a product must be augmented by delivery, installation and/or enablement/training, UX to use/deploy/develop, ongoing support, and the inclusion of complementary products.[2] It's a lot. Your product is not some school project that is narrowly defined and time-limited. Your potential customers depend on you to deliver all of the above in their context, or they buy from someone else who can deliver. "But Dan, that's not very innovative or disruptive!" No, it's not, but as long as the customers have the dollars and you don't, they are the ones who call the shots.

So, here’s key advice: talk to your potential customers to understand the full scope of their problem and the context within which they want to solve it. Learn to have open Marketing conversations, not Sales. Even a handful of such conversations increase your chances of success immeasurably.

Then, create a map of all the augmentation your product will need. I gave a non-exhaustive list of things to consider above. Not every one will be important for every product or context, but spend a little time thinking about each before writing any off. And – importantly – you don’t have to provide every one of those things! Make strategic choices of which you’ll provide and which you’ll find partners to provide. What is the most efficient way to provide all of the pieces of the augmented product?

Of course, the answer changes over time as you learn more and as you scale. That tells you that you need to revisit this analysis regularly, perhaps as often as quarterly. Keep in mind that it will be absolutely key to growth-round investors if you’re fortunate enough to get that far.

And a strategic note: understand that the value of the augmented product will be divvied up among all of your partners and you. If you’re not providing the whole solution – and you should not be! – assume you can negotiate with specialists in areas you won’t provide. And negotiate fairly. This is not a zero-sum game, unless you fail to deliver the full augmented product to paying customers.

Development Enablement

Story time:

In 2006-8, I was working on commercialization of the Cell BE processor. At the time, IBM provided the processors for all three major gaming consoles and Cell was the processor in Sony PS3. IBM had the rights to commercialize its use outside of gaming consoles.

Cell was a beast for its time: 9 cores running 10 threads, including 8 in 128-bit wide Synergistic Processing Units and a cache coherent bus. It was a really remarkable achievement for a single-chip processor.

And it was infamously hard to program. Every customer told us that. I took that as a charge and argued strongly that if we were ever to succeed in commercial markets, we needed software enablement to make that easier. We needed more than the SPU compiler – we needed a programming model.

IBM is a high-performance computing company.[3] They won the contract to build Roadrunner, the first petaflop supercomputer, based on Cell. All software resources were sucked into that project and I never got my enablement. At the same time, a no-name startup with parallel processing chips introduced this thing called CUDA…

The moral of the story is obvious: product enablement, especially in hardware, can defeat significant disadvantages in the market. This was a $B mistake by IBM, and one that at the time was foreseen.

So, first thing: if your product is going to depend on developers’ using it, make sure you allocate sufficiently for enablement. Remember, delivered performance is the product of your product’s performance and the developers’ ability to tap it. Balance these two.

One strategic note: as you think through (customer) development enablement, realize two important things. First, enablement is a spectrum. In hardware, it’s from bare metal to basic structures to libraries of useful functions/snippets to fully implemented features. Pick what fits your means.

And second, realize that what you don’t provide needs to be provided by someone so that the customer sees a complete solution. As above, negotiate fairly with partners: you want them to get a piece of the pie you’re creating together.

[1] It’s a bit like how everyone who can sing a little decides that they are an “artist” but only a few make it.

[2] Continuing the analogy, there is a reason the record industry has A/R, producers. PR, etc.

[3] Don’t laugh. A Z-Series Mainframe has capabilities and reliability that are amazing.