Be focused on something that will have high value to someone elseRead more...
How do you find what the minimum features are?
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.
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.
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.
- 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 early evangelists
(Image source: Linvio)
Read more from our "Lessons and advice" series
Factors to consider when taking debt vs equityRead more...
What I learned as an entrepreneur, and a humanRead more...