In Customer Development the goal of a minimum feature set is to pare the features of the first product release to the minimum necessary for early customers.
But finding what those “minimum” features are can be an adventure.
All the Data and Not a Drop to Think
We started Epiphany to solve the “too much data but not enough insight” problem. During the 1990’s large corporations had bought different software applications to automate each part of their enterprise – finance, customer support, manufacturing, sales, etc. Yet the data these applications collected were accessed via reporting tools from the IT organization. More importantly, the data existed in “virtual silos” with each functional system walled off from the other. The finance system didn’t talk to the sales system which didn’t know the manufacturing system even existed. (Queries like – compare the sales data of green dresses versus the blue ones, with how many of each does manufacturing have in inventory, and what does finance say the gross margin by region of these product are – would be hard to answer because it required combining data from three incompatible applications.) It might take days or even weeks to get a report. And if that question led to another one, add more days or weeks to get the next answers back. And once you got the data you asked for, it still took weeks or months for a marketer to tease out any customer insight and trends from the data. And if you actually want to respond to shifting customer behavior by running a new marketing campaign (ads, email, etc.,) it would again take weeks or months.
An Epiphany
Initially our engineering team designed three products to solve these problems: an On-Line Analytical Processing (OLAP) tool – think of it as a multi-dimensional Excel to search through reams of customer data, data mining tools to search for patterns in customer data, and a campaign manager to combine all the data and generate customer specific ads/emails. And underneath these products was our own data warehouse (a place to store all this different data) and our own tools to Extract, Transformation and Load (ETL) customer information from existing enterprise applications like SAP, PeopleSoft, Oracle Financials, etc. And back then the radical notion was that you could view this information anytime and anywhere through this new technology called a web browser.
You’re An Idiot
As a founder my first job was Customer Discovery – getting out of the building to listen to customers and see whether our understanding of what problems customers had was correct, and if so whether our product as spec’d would solve that problem. Over time one of our hypothesis was that our product should be a great fit for companies who had lots of customers, tons of data on them and wanted to quickly come up with new marketing campaigns.
We had put together an advisory board, and one of our advisors was the VP of Database Marketing at Schwab. She was incredibly generous with her time and said that our system might work in their application. She introduced me to five other Database Marketing executives who essentially said, “If you get a system working at Schwab, we’ll have to buy one as well.” You couldn’t get much better than that. I thought we had found our first Earlyvangelist and first market.
But each time we met and she looked at the technical details of our system, and politely told me I was an idiot and my engineering department was even dumber. It took two meetings before I finally got what she was trying to tell me – we understood her problem all right, but our architecture was missing the most important feature to solve it. Our database schema didn’t include “householding” and without this feature was she could never buy our system. (Householding means recognizing that two or more people at the same physical address live together. This feature was crucial to direct marketers who did not want to send multiple ads to the same address.) Our data warehouse didn’t have the concept of householding in its schema. And no amount of sales and marketing hand waving was going to fix the problem.
Founder Too
My engineering co-founder and I had a great relationship. If I thought I discovered a customer with a feature we were missing he was coming out to hear it himself. Just don’t waste his time on the first “getting to know you” meetings. We had agreed that Schwab and the database marketing application sounded like the right fit for the technology so he was as eager as I was to figure out what we were missing. So now, a week later, he’s in San Francisco with me listening to the Schwab VP of Database Marketing and her engineering team go into a deep technical dive about what our software needed to do. My partner asked five or ten questions, everybody nods and the meeting was over.
What Do You Mean Page 6?
We got back into my car for the drive back from San Francisco to our office in Silicon Valley. 5 miles goes by and we’re talking about the weather. 10 miles goes by and he’s talking about his kids, and 20 miles goes by and we’re talking about my kids. Finally, unable to stand it any longer, I ask, “Ben, what are we going to do about the Householding feature that Schwab asked for?” In an innocent and deadpan voice, he replied, “Well just take a look at page 6 of our spec.” I had to think for another couple of seconds until I said, “What do you mean page 6? Our spec only has 5 pages!”
He looked at me and smiled as he said, “Not any more.”
Our first order from Schwab came the next week.
We had just iterated the product and refined the minimum feature set.
A week later we sat down to figure out what other feature we would toss out to make room for this one.
Lessons Learned
- Founders’ start with a hypothesis of what the minimum feature set is.
- Your customers teach you which features actually matter by whether they will buy.
- You swap (not add) features as you learn what will optimize market share of earlyvangelists.
Share this:
Filed under: Customer Development, E.piphany |
You can’t get away with not telling us which feature you tossed out!
Interesting and that’s not an average customer.
This is actually very similar to your “seizing opportunities, negotiating commodities” blog post. I don’t think you make it clear enough that the Schwab VP of Database Marketing was one in 100 or one in 200 customer. Someone you did not want to lose and therefore re-arranging your roadmap to hone in on satisfying her was strategically astute.
Your earlyvangelist checklist gives founders the ability to spot knowledgeable early prospects who will contribute not only revenue but deep insights that will allow you to build the right product. You should consider elaborating on it as I think there is a lot more going on there. It’s part of the same “customer co-creation” or shared innovation that takes place early in a market when even successful companies are willing to “outsource” to find a solution to a compelling problem.
This brings me to a question I wanted to ask for a long time.
Steve, what do you generally think about the services model for customer development in the enterprise space? Perhaps your product at Epiphany was reasonably mature and you didn’t need it, but otherwise – wouldn’t it have been useful to build your OLAP system as a custom-developed thing for Schwab, offering reduced rates in exchange for keeping property of the code? One would think it’s a good way to understand customer needs.
I like how you worked with your advisory board and their contacts to lead you to identify your Earlyvangelist. Most people think of advisors as “product advisors” and don’t leverage their network for finding and introducing your first prospects and customers.
Great post. I have one aditional question. How many iteration with early evangelist is the best or the sales should go slighty up to know that there is minimum feature set? Sorry for my english.
Hm. I am trying to imagine an employee of a company arranging buying from a company where this employee is an advisor…
Does this not amount to a blatant conflict of interest?
[…] I offered that at Epiphany, my partner Ben’s office was the first place I would go when I thought I had new “insights.” And we’d run them to the ground for days before we’d even let anyone else know. Most of the time after a few days of thought, these insights were really not much better than the current course the company was on. Or by then other customers would tell us something quite different. And the rule was we weren’t changing anything about the product architecture until Ben and I agreed. Which required Ben hearing from the same customers I did. […]