We built it but no one came
Technology-driven companies still believe, 'If you build it, they will come.' Out of the brilliance of the engineers comes good fortune. After all, customers don't know what they want, so why listen to them? But the thing that engineers love most about their technology is precisely what prevents them from making money. Money is in AOL users, and yet high-tech firms want to provide high-speed DSL with static IP addresses for web servers from my home. No, home users don't need all of that. They simply want to get on email instantly.
If you understood the market, you would know that.
Why should we be market-driven? According to research published by George Day in The Market Driven Organization, companies that are market-driven are 31% more profitable than companies driven by something else.
And don't confuse 'customer-driven' with 'market-driven'. Customer-driven usually means deal driven or contract driven (in other words, sales driven). The danger with contract driven is that we might build something that satisfies a market of one. Sales people always say, 'Let's build it for my customer; I'm certain that many others will buy it too.' But they rarely do. Being market-driven lets us leverage our precious development resources to build something lots and lots of people will buy, rather than a few customers.
Market-driven starts with listening to the market, looking for unsolved problems, and quantifying what we learn. If we uncover a problem to solve, before we turn it over to development, is it:
- Urgent? Is this a problem people want to solve now?
- Pervasive? Does this problem exist for an entire market segment?
- Valuable? Is this problem critical enough that people are willing to pay someone to solve?
The dot bombs missed the last one. Eyeballs on the website were not enough to sustain a business. And when they went back later and tried to 'monetize' the business, they found the answer to the last question was 'no, the product wasn't valuable.'
Market driven companies build meaningful products by observing customers and potential customers at work. This observation is usually a key function of product management. Product managers can serve the company strategically (by documenting market requirements based on market observation) or tactically (by being 'demo boy' or 'brochure writer' or 'icon picker.') The tactical role doesn't leverage the value of product management at all.
Product management involves many activities, from strategic to tactical (click graphic for full-screen view). In order to be effective with the tactical activities on the right side of the chart, we must have completed the strategic activities on the left. We determine product features, not based on what is 'cool' but based on the problems we encountered in the market. We validate the success of the product and the chosen market segment using Win/Loss analysis (which is a product management function, not a sales function).
For example, the telecommunications industry is going through huge change right now. Large, established companies are challenged by satisfying their current customers (and continuing to meet revenue and profit targets) while moving into new technologies to protect their future. Data and voice technologies are converging, the Internet is ubiquitous, and communications infrastructure costs a lot of money. New, entrepreneurial companies are attempting to take advantage of the flux by going after untapped markets and by going after the vulnerabilities of the larger, slower-moving competitors. Who is going to win? Is it a zero sum game?
The winner is not going to be the companies with the most features. It's going to be the ones with the right features.
We have too many features, and not the right ones
Technology-driven and sales-driven products tend to have a lot of features. But they are often not the right ones.
For example, here are products that have too many features, and not necessarily the right ones.
- Cell phones. Mine has a calculator function. On the surface, that seems kind of cool. One less device to carry. But the execution is terrible (the phone doesn't have +,--, or / keys). Worthless. And a cell phone shouldn't need a 132-page user guide! But wouldn't it be nice to be able to recharge it anywhere, anytime, without a special cradle? Or better yet, get a reliable signal in Silicon Valley, the highest tech of high tech locations?
- Remote controls. Mine have too many buttons. And I have too many remotes--TV, satellite, VCR, DVD, stereo, CD changer. I tried a universal remote, but it doesn't work very well with all of the devices. It reminds me of the early digital watches where you had to press those teeny buttons (with a paper clip) to the 'function' you wanted to change. Then you pressed the other teeny button to change the date or time. It was easier to buy a new watch during Daylight Savings time rather than figure out how to change the old watch. But why hasn't anyone made a remote with buttons we can read in the dark?
- Digital video cameras. Mine is terrible. It has a 100-page user manual and I still can't figure out how to connect the camera to the TV and VCR so I can copy those teeny tapes to a standard VHS tape so my mom can watch it on her VCR. It takes both digital movies and digital still photos (with a flash!), but it has dozens of menus you have to cycle through just to figure out how to erase the digital photos after you've downloaded them so you can take more. Way more features than I need and too complicated for the most common functions!
As we move to new technology platforms, we ask ourselves 'which features should we provide?' The answer is not necessarily the ones we have always had. It is important for us to understand the needs of our target market (assuming we have a well-defined target market, not just a shotgun approach).
- What's important to them?
- What do we need to put in the product that will delight them, make them become outstanding references, tell their neighbors?
- Which are checklist items that shouldn't be over-engineered?
- Can we solve problems that haven't been solved before?
The last question is a true measure of a market-driven company. And it isn't done through ivory-tower thinking. We do this by knowing our prospects and customers better than they know themselves. Get out in the market and spend time with them, uncovering problems they aren't even articulating. As voice and data technologies converge, what new problems can we solve for people that older technologies couldn't solve? Does the technology have the reliability currently demanded for voice-only technologies? Is there a segment of the market that is OK with this while the reliability is improved? Can we solve new problems TODAY with current technology capabilities (and make money) while the back room R&D continues to improve the reliability of the voice-data convergence? 100% voice-data convergence might be 'ahead of the market'. If so, it's probably also ahead of the revenue. So we need to figure out how we can make money in the meantime.
If we are moving to new technologies that require our existing customers to make huge investments to migrate, what will motivate them to move? We should be careful not to base our business plans on aggressive migration of existing customers. They will move at their own pace, not ours. It is arrogant of us to think they will migrate on our time schedule. They have additional costs well beyond the cost of our solution--infrastructure, personnel, implementation, training, and conversion of existing systems, to name a few.
Shouldn't we be listening to the target market of the NEW business to help us determine what problems we should be solving with new technologies, not only listening to our existing customers? Let me repeat this important point--we should not only listen to our existing customers to determine what problems to solve with new technologies. We should also listen to people who have no reason to talk to us--those companies in the market who are NOT looking today. How are they surviving without our technology? What problems do they need to solve to improve their businesses? This is the future of our products.
If we only listen to our existing customers, and respond only to their feature requests (which are often not addressing needs of the market at large, but we do them because they are noisy), we run the risk of building a product only existing customers would buy (at their pace, not ours).
Develop for Regular People
Part of the problem with high technology products is the people who design and build them. We are immersed in the technology. We are technology enthusiasts. We live and breathe new technology. But, we are not regular people. Just because we (the technologists) 'get it', doesn't mean the rest of the market (the mainstream people who pay our bills) get it. Not everyone has a Palm Pilot, a home network, DSL, or spends more than an hour on the Internet every day.
Regular people don't have a friend in the business. Something like DSL is incomprehensible. After all, the phone company engineers and cable installers can rarely set it up in one trip! If you want to take high speed Internet to the masses, take a wire, plug it into the computer, self-configure it, and start surfing. High-speed internet can be as easy to use as a toaster (and must be, if we want to make money).
Develop for regular people. Maybe the problems we need to solve for regular people are complex. Then mask the complexity! Intuit was very successful doing this with Quicken. They learned what regular people needed by spending time in people's homes, watching how they managed their home finances. Quicken was the first finance package to use the checkbook metaphor, something regular people already understood. Quicken was hugely successful, and even with dozens of competitors, managed to gain 75% market-share because it was easier to use. It was the first product to take a customer-oriented view instead of a data-centric view.
Stop being driven by the technology
Many high technology companies are driven by the technology rather than by the business problems that need to be solved. Customers want to be sure they aren't in some dead-end technology that will prevent them from adopting future products, but unless your customers are 100% early adopters (and usually there aren't enough of those in a market to sustain us for very long), we can't be delivering technology for technology sake. We must use the technology to solve problems for our market. And when we deliver solutions that include infrastructure investments in a particular technology, we need to make sure we are delivering substantial value to the customers or they won't make the investments or switch to a 'newer, better, faster' technology. Even if we want them to.
Engineers often throw in features because they're a cool use of technology. The night before the press announcement for Apple's Newton (one of the first personal digital assistants), a lead developer added a thermometer function. Neat. It measured the temperature INSIDE the Newton. The thermometer was a dumb idea but everyone just winked at how cute it was, when it should have been a firing offense. And yet, handwriting recognition was still crashing the operating system.
If you want to become market-driven and create products people want to buy, start by looking for unsolved problems in the market. Ensure that they are urgent, pervasive, and valuable.
Challenge your product management people to follow the Technology Product Marketing grid to bring market problems to development.
It does not have to be a zero sum game. If we all continue solving new problems for people, problems lots of people are willing to pay to solve, we can reap the rewards and expand the markets well into the future.
And they will come.
Looking for the latest in product and data science? Get our articles, webinars and podcasts.