To Netpreneur Exchange HomeTo Netpreneur Resources

AdMarketing | Funding & Finance | Netpreneur Corner | News Center | Quick Guide | Home

Events Transcript


Go to: Summary | Video | Speakers | Resources | Back to Archive  

If You Build It, Will They Come?
Product Strategy and Management Insights
page four of four | previous page

the audience: q&a

Q: Paul, in one of your slides you had four circles with product management, sales, marketing, and engineering all beautifully integrated. What is your advice for a company that has the product management people going one way, and the sales and marketing people going another? Who decides? Can you think of examples where action was taken by the management or someone else in the company to force the issue?

Mr. Mauritz: I can think of a specific example, a company that is doing pretty well. The CTO had stopped being the person responsible for driving the product, and somebody sat down and said, "We're building product, but our customers are not buying it like they used to. What are we doing wrong?"

            The answer was in the evolution of the company. A small group of people had been working out of a single room, driving all the time. As the company grew, people started putting them in this new building or that new building and the communication was the first thing that broke down. What this company did was to say to the CTO, "We're not communicating. We don't want you to do this for the rest of your life, but go back and do it again. Don't stop communicating. Be the catalyst to put it back the way it was, and implement a process. Find out what is wrong and fix it.” So the CTO stopped being CTO and went back to being the product manager. He put in place a set of processes to get that flow of communication going and to get people to understand that just because I can't see you every day doesn't mean I'm not doing what I said I'd do, or you're not doing what you said you'd do. You can drive it by patting the person, but that person probably wants to go do the things they're doing anyway. If you don't fix it through process, communication, and culture, it will break again.

Q: What are some of the process steps you can use to balance the needs of your buyers and the needs of your users when those people are different? Are there any steps that help get the balance back?

Mr. Mauritz: There are, and I think Phil touched on it. The first process is knowing the difference between the buyers and users. I went to sales school a long time ago where I learned that first you identify your buyer. The first process is to understand them, then the segment, and you have to say different things and address their needs differently. Maybe you have your direct sales force doing high level account management focused on the decision maker, and a different sales person or sales channel address the needs of the users. There are lots of process steps, but it's really about doing that up-front homework to understand: Who decides what to buy and how do they decide? Identify them up front, then follow through in your process to make sure that you address all their needs.

Audience Member: By having a group of sales strategies?

Mr. Mauritz: That is one way to do it. It involves looking at your business in the market. I spent a lot of time talking about process, but there isn't any single process that everybody in this room wants to run away and apply to their business. It doesn't work that way. Process is a repeatable, defined way to do something. You don't necessarily do it the same way more than once in a row. It's not a magic bullet you can shoot and be successful, however, it's also not something you can ignore. I don't know if your sales process is on the right channel in your specific case. You really need the analysis that I talked about, and you need the process matched with experience. Those two things will help you figure that out.

Mr. Carrai: As Paul said, as you define who the customer is, who is using it versus who is buying it, it differentiates between the set of issues and the set of needs. A classic example is testing software. What developer wants to test software? What engineer do you know who actually spends time thinking at night, “Gosh, tomorrow morning I'm going to spend all day testing software!” However, what development manager doesn't worry, “I hope this thing works!” If you have a user of a product, a developer, and you have a buyer of a product, a development manager, how do you harmonize that situation? One of the ways is to think about what the problem domain is and how you attack it in a very specific manner.

Q: How do you deal with patent issues?

Mr. Carrai: I'm not quite sure of the nature of the question. If it relates to somebody who is imposing their patent on what you're offering, it's a very delicate thing. If it's that you are going to market with something that is patented and you are trying to defend your patent position, that's something quite different. There was a time when everybody who had some technology went out and got a provisional patent or process patent. Quite frankly, I think most of that was complete crap. Some of you may have done that, so I apologize, but the reason why I think it was complete crap is that they went out and tried to defend a position that nobody may have cared about. It sounds so simple, but I've seen a lot of provisional patents that nobody really cares about. It's a notice that the US Patent Office hasn't a clue as to what you are building.

Q: Many times it seems that the steps in the process are fighting the last war. How do you optimize your process for current needs?

Mr. Mauritz: You can look at process in one of two ways. It's absolutely to fight the last war, fix the last error, prevent the wheel from coming off in the same way. I don't look at it that way. I look at it this way. My experience says that I went through the door before I opened it three times. That was really painful. What could I do differently? I could open the door. More importantly, it's a function of: How do I know that there's a door out there that I have to get ready to open? How do I know what kind of door it is and what kind of force I have to use? To me, that's process. Process is enabled by the research you do to get a fuller view. You're right, you can go backwards, or you can go forwards. To me, process has always been a vehicle for looking forward, to figure out the things I have to know about the door out there somewhere that I can't see. Where is it? How do I open it when I get there? How heavy is it going to be?

Q: If it's key to understand the market and meet the customer’s needs, why call it product management?

Mr. Carrai: I think that the reality is, especially for technology companies, product management is really business management. It’s understanding what it is you're offering, who you're selling to, and how to construct your organization. One of the things we touched on a bit is the harmony between your organization and what you're delivering. The example of that is, if you're going to market with a strategic solution that changes the way people think about process, and you're trying to sell it over the phone, your success rate is going to be fairly low. If you are going to market with a fairly practical product that sells for under $5,000 a copy, that isn't going to be pervasive in an organization, and you're trying to sell it with a direct sales force that is getting, confidently, $200,000 at plan, you're probably not going to make any money. If we think about product management fairly, from a more global standpoint, it is business management. My opinion is that in the technology-oriented company, the best product manager is often your CEO because it's not only about what you're delivering to the market, it's about how you think about your business.


Q: Suppose that you're a product company that fired without aiming, maybe a high burn rate with limited success. What now?

Mr. Carrai: You drop back about 12 yards and punt. No, just joking.

            One of the biggest problems we've had in the last couple of years -- and it's easy to say in hindsight -- was not recognizing when the wheel was coming off the cart and not cutting your expenses quickly enough. I've seen this in many different cases. Say that you have X number of people and Y amount of money. The belief was that we needed the people because we needed to figure out what our next step would be and what our stage was. But you don't really have a comfort level. You fired, and you have no idea where the bullets went. You aren't even sure what gun it was that you fired. If you're in that situation, the only advice I can give you is that we are back in the fundamental world of businesses that existed pre-1996. Cash is king, and you do whatever you can to preserve it. If you don't have a defined market, a defined set of customers in front of you, if you don't have people not just giving you their business but paying you (not only do you have to sign an order, but you also have to collect the cash), then you really need to get your burn rates as low as you possibly can. Cash is absolutely king. How you handle bookings of revenues is irrelevant in this marketplace. So, the only piece of advice I would give you is that if you fired and you are not exactly sure what to do, but you have a million dollars in the bank, that is a completely different position than if you fired and are strapped for cash.

Q: Paul, in your B2B eCommerce startup, what were the top three things you believe caused it to fail? What would you do differently if you did it again?

Mr. Mauritz: Boy, have I spent a lot of time thinking about that one. I don't know just three things. Our biggest mistake was that we got caught up in what Phil just talked about. We got caught up in the hype a little bit, and, while we set out to solve a problem, we could clearly have solved lots of problems. We listened to a lot of people tell us that we should get big fast, and we didn't challenge it. We didn't say, "Okay, but who's going to pay us to get big fast? Who are the customers who are going to say, ‘I'll completely turn my business on its head and do business a whole different way so I can win using your solution?’" We didn't do that. We got caught up in getting big fast.

            The second thing is that I talked a lot about process and a lot about listening. We stopped listening. On the one hand, we stopped listening to our engineering team that was saying, “You're asking us to do a lot.” We had five product management teams supporting a big engineering force, big at the time, anyway, and we stopped listening to the engineers. We would say, "We have this customer who will sign tomorrow if we could just do this." The engineering team would say, "We can't do that, or, if we do, we can't do this." We stopped listening at some point in time. Everybody does. Speed kills, you know. It’s an old saying, but it does. You're going too fast, trying to get too big, too fast; trying to do too many things too fast, and you stop listening.

            A third thing is that we started out with four guys who knew each other really, really well. We were all friends and we went into this business together. At the end of it, we were not all friends anymore, so the other thing we did wrong is that we went into business together because we were all friends, not necessarily because the four of us were a lot stronger than we were apart. Did I lose a friend? I didn't, but a couple of guys lost friends in that deal. What the friendship masked was that, although we were really smart guys, in our opinion -- I'll tell you all day long I'm a really smart guy -- we probably weren't the right four guys. There was a time when we didn't hire the next four guys to win. The team is really important.

Mr. Carrai: The only thing I have to add to that is that I was involved in a business that, in 1995, had an idea for a product that was going to address the wireless space. If 2001 is early for wireless, can you imagine 1995? The reality of that business is that its genesis was in a service issue. One problem is that it was a service industry that had a product. It doesn't happen very often and, in this case, it wasn't going to happen. The second problem was that the product we offered was sold to a customer that was very service intensive, and why they bought the product had nothing to do with the underlying technology. Why they bought the product had everything to do with the relationships that were established, in some cases years beforehand. Two fundamental problems that, thinking back, I should have been smart enough to recognize. The first was: How do you turn a services company into a product company? If you use the statistics Paul gave on why products fail, you can probably take it down to maybe less than 5% for how many services companies successfully launch products. The second problem, which I think is an important issue as well, is that why people buy a product may be different than why you wanted them to buy it.

Q: Can you say more about how to differentiate customer needs from customer wants?

Mr. Mauritz: I wish that I could tell you it's a science, but it's not. At some level it’s salesmanship, which is one of the reasons why I believe that it's so important to have a sales force that could very well be your CEO talking to customers very, very early. There are methodologies. You can go spin selling and really luck out, where you spin a solution into a need. It teaches you techniques to differentiate between needs and wants. You can follow whatever methodology you want, but, at the end of the day, look at yourself. Me, I really want a Ferrari, but I don't drive a Ferrari. Most of the time, I drive a minivan because that is what we need. I don't want to drive one; I want to drive a Ferrari with myself and maybe just my wife, but we have two kids with lots of soccer equipment. If you talk to me, it's really easy for me to say, "Yes, I really want that Ferrari!” But I just don't need it. What I need is to throw some soccer balls in the back and haul a bunch of kids around.

            You get there by asking questions. You can call it any methodology you want for asking questions, but sales is sales. How to differentiate needs from wants is a function of really boring into their businesses and understanding how they're going to be successful. I've been in sales management. If you call in a salesperson who has not been very successful and ask, “Why are you talking to the person you’re talking to?" They'll tell you it’s because they're the decision maker. Great. So, you found the decision maker. How are they successful? What kind of business do they do? Do they get their bonus when their revenue gets hit? Are they in product development? Do they get a bonus when they deliver a product on time, or when they deliver a lot of units? That's what they need. One trick is finding out how they get paid. That is a need, not a want. It's a first differentiator, and it comes down to salesmanship.


Q: Can you discuss price setting? What is the strategy? Does low price drive volume?

Mr. Carrai: In my opinion, once again the fundamental questions you have to ask before you think about pricing are: What is it that you're offering? Is it strategic or tactical? How pervasive is it going to be in the organization. Are you changing a process, or are you solving a particular utility problem within a company? Do you have an expertise that is valued for a services company, or do you have something that is more commodity-oriented?

            Here are a couple of examples. How many customers do you think that SAP has worldwide? If you answered 800-1,000, that is probably about right. SAP is a multibillion dollar company. If you ask how many customers Veritas has worldwide, 10,000 is probably low. Something like 20,000 may be correct.

            What are they offering? Veritas is offering backup and recovery, whereas SAP offers a complete process orientation product. They’re very different product lines with a very different impact in the customer base and a very different set of people they're dealing with. If you are SAP and you say, "I'm going to execute a high volume strategy, so I'm going to price it low," do you think that anybody would care? Well, they'd certainly buy it from you, but the reality is that since you're dealing with a process-oriented problem, customers are going to expect to pay process-oriented prices for it. If you come in with a $15,000 solution, one of two things will happen. One is that you'll sell your 1,000 customers at $15,000 apiece, but, more likely, they'll look at you and say, "Clearly, you don't have any idea or understanding what my market is." Conversely, if you walk in with a storage product and say, "Because you're going to be able to save a substantial upgrade in your network, you should pay me $5 million dollars for this product," most likely you'll get very little response from the customers you're dealing with. So, the first process issue I talked about is defining exactly what set of problems you're solving, what set of needs you're addressing in the customer base, and how pervasive those needs are, then price your product accordingly.

            The reality is, talking about IT for a second, that you have a set of products that are priced at desktop levels that are under $1000, you have a set of products that are priced at departmental server levels of around $50,000, and you have a set of products that are more framework-oriented and have an entry level price somewhere in the range of $250,000-$500,000. We can go develop a market all we want, and we can define all we want about all the different pricing algorithms that you might think about, but the reality is that this is kind of how product prices fall. Why? That is how people are comfortable buying, and how you define what you do with your pricing has everything to do with what you offer.

            One quick point: Somebody asked me earlier about how you know what price to set, especially for the strategic product. The old story says that it's as high a price as you can say without breaking a smile. It sounds funny, but I recall setting prices at the last company I was at. We had a product for the enterprise and somebody came in and asked, "What do you think we should charge for this?" A fairly large customer was looking to buy it for a number of sites. The original quote was $40,000-$50,000, and we added a bunch of things to it, so I said $350,000. They asked, "Why $350,000?" My response was, "I don't know, but I didn't smile. Give me a second, and I'll figure out how we justify it.”

Audience Member: Did you make that sale?

Mr. Carrai: Actually we did, and I'll tell you the other side of the story. There was another sale for the same product, a large customer for whom the original price was $45,000. The response back was, "Clearly, this is not something that we're going to want to implement at the scale we need because there is no way we feel comfortable with a product that is only priced $45,000." Can you think of a worse thing for somebody to tell you? “You should have charged me more for this?”

Q: Can one address the needs/wants problem with a product line that covers a range from high-need/low-want, to low-need/high-want, or does that just confuse the customer or the salesperson trying to sell it?

Mr. Mauritz: The latter would be what I’d worry about more. I guess there is a range. My opinion and experience are that you have to hit the needs. If there are six things that the customer needs the product to do, and you only have five of them, that is trouble. You can pile lots of wants on it, but, even if it's blue and it's round and it’s cool, if I need it to work on a desktop and it doesn't, I don't think you can win that sale. I guess that if I'm a fabulous salesman, I might win, but my customer won't be all that happy, so it will cause me trouble at some point in my cycle. There probably is a balance, but there are going to be some core needs. If the customer says that there are six things he needs, but he is using somebody else's product that only has five of them, that's not a need, it's a want. If you figure it out, you can sell against it. I don't know about a ratio, but I would say a balance is good, but you have to hit the needs.

Mr. Carrai: Take the examples of document management and content management. Did you ever wonder why the document management players like Documentum or FileNET have never been effective in the Web management area? In some respects I think it's exactly Paul's point. In both cases you have to fix your management process and manage your workload and manage your processes, so why wouldn't the document companies be able to garner a substantial footprint in the Web publishing space? Clearly the set of technology they're bringing to the market is similar. I think there are two issues. First is that the one need which they probably weren't addressing is that the Web people need their interface into the Web publishing tools. In Web content management, how you interface with other aspects of what you use to create your website is incredibly important. You may have all the document infrastructure and file management infrastructure that is required, as well as the workload that is required to manage it, but there are a set of needs that are incredibly important to you that they just haven't thought of. The second reason is that people who are buying those sorts of things are probably different. A webmaster who is buying an infrastructure for building a website and an engineering department that is trying to control their documents are very different. Even though five out of six things may be similar between a document management system and a content management system, it's that one thing that created a multibillion dollar marketplace for a whole new set of competitors.

Page four of four | End

Statements made at Netpreneur events and recorded here reflect solely the views of the speakers and have not been reviewed or researched for accuracy or truthfulness. These statements in no way reflect the opinions or beliefs of the Morino Institute, or any of their affiliates, agents, officers or directors. The archive pages are provided "as is" and your use is at your own risk.


Go to: Summary | Transcript | Video | Speakers |  Resources | Back to Archive  

AdMarketing | Funding & Finance | Netpreneur Corner
News Center | Quick Guide | Home

By using this site, you signify your agreement to all terms, conditions, 
and notices contained or referenced in the Netpreneur Access Agreement
If you do not agree to these terms, please do not use this site. Our privacy policy.
Content copyright © 1996-2016 Morino Institute. All rights reserved.

Morino Institute