Ivan Chong: The I-Blog

Monday, February 28, 2005

Sarbox Impact on Product Roadmaps

A friend of mine emailed me the other day asking to compare notes on presenting product roadmaps. He runs Product Management for a well-known, well-funded startup offering enterprise software. Having been in the business for quite a while, he has great experience presenting product roadmaps. However, the corporate controller recently approached him and expressed concern over the content of his roadmap presentations. Specifically, the implied commitments created exposure from a revenue recognition perspective -- according to the controller.

In general, this first year of implementing Sarbanes-Oxley is resulting in lots of anxiety that works its way across all parts of the organization, not just Finance and Accounting. The fear of legal exposure is so great that many areas of ambiguity are interpreted with extreme conservatism. This is starting to hamper a company's flexibility to do business.

I once had breakfast with a CIO who started the conversation by stating -- "I want you to tell me everything you know about your future plans and direction. Don't hold anything back due to fear that I'll hold you accountable. I pretty much assume all vendors lie anyways." Nice way to break the ice. With regulatory compliance taking up everyone's attention, I can't imagine what that conversation would be like today.

Sunday, February 27, 2005

Differentiating Differentiation

One of my biggest daily challenges is to stay genuinely interested when a partner gives a corporate overview. Every company in enterprise software claims they are unique because they lower costs, mitigate risks, and increase productivity for IT. Differentiating is a really tough challenge in this industry.

I've observed roughly four ways that enterprise software companies try to differentiate:
  1. Product Trial (or Proof of Concept)
  2. Demo
  3. Messaging
  4. Customer References
Product Trial
Many IT buyers these days insist on a test drive before a significant purchase. As might be expected, many vendors will try to game the evaluation by biasing evaluation criteria and weighting to their product strengths. All in all, heavy reliance on product trials to differentiate is extremely expensive and can have some downside risks. For example, saavy competitors may use their own efforts sell around the technical evaluators, positioning their own solution as superior in high level vision. The reward for focusing too much on a successful product trial may actually be to get pigeon holed into a lower level feature function offering. Also, there is significantly more risk relying on product trials since it is more challenging to set the agenda on value perception. While product trials may be necessary, the task of differentiating must be performed at a higher level in the sales process.

Demo
Giving a good product demo for enterprise software is not easy. A common problem for presenters is to treat the demo as a training session for the audience. The purpose of a sales demo is not to educate the audience on every last feature of the product. Sure, features are shown in the demo -- but with the sole purpose of convincing the audience there is unique value. The demo should focus on clearly proving the product is unique at solving relevant customer problems. It is essential that you demo capabilities no one else can offer. Another common challenge in giving demos is that value must be demonstrated from the audience's perspective, not with respect to the previous release, not from the viewpoint of the product group, not from the perspective of how hard it was to code. One take away from Guy Kawasaki's The Art of the Start is to always answer the questions "so what?" and "for example." I've found these two questions really helpful in focusing on keeping proper focus on audience perspective.

Messaging
Really great marketing results in messages that everyone can easily understand and that leverages your competitors own positioning against them. For example, when I was Oracle in the early 1990's, one of the key messages was around portability. You could run the Oracle RDBMS the same way on any operating system platform. In the Oracle Tools Division, we took that mantra and applied it towards client GUI's. You could use our Oracle tools the same way on Motif, Windows, Mac, character-mode terminals, etc. We competed against PowerSoft and they differentiated against us brilliantly with their messaging. Their message was that they focused purely on one GUI -- Windows. They managed to use our own messaging against us. Hats off to them.

Customer References
An all too often overlooked means of differentiating is via customers. When I evaluate partners, I invest most of my time following up on their customer references. I find out an incredible amount of information from talking to a vendor's customers and I have a much higher comfort level in my understanding of their product offering. Cultivating solid customer references is hard work and requires constant attention. However, of all the possible ways to differentiate, it offers the most sustainable advantage.

Sunday, February 13, 2005

Some Buy-side Perspective on Venture Partners

More and more these days I hear from entrepreneurs who are looking to bootstrap their new startup ventures. Many cite bad experiences in prior dealings with venture capitalists. This is their motivation for seeking alternate funding. I have my own horror stories about “vulture capitalist” behavior from my last company. One of the VC’s preyed on the naiveté of the CEO and diluted the other two venture partners (as well as the company founders) in order to gain a greater equity percentage. However, having spent some time in corporate development for my current company, I’ve come to appreciate many of the benefits of working with venture partners.

Venture capitalists naturally place a premium on cultivating their reputation and their network. Many view their credibility and integrity as the only means to achieving long term sustainability in their business. On several occasions, venture partners have backed off a proposal, once I explained my objectives and they understood the deal would not result in good business. One partner once encouraged me to pursue a build option even though the deal involved one of his portfolio companies. His fear was that if the transaction turned out badly, it would negatively impact his business as well as ours.

Venture capitalists pride themselves on their matchmaking abilities. One partner was invaluable in brokering a multi-party agreement in which I participated. When discussing his portfolio company, I mentioned that I would value any synergy the deal created with another company with which I wanted to partner. Not more than fifteen minutes passed after I got off that call, when the VC partner called me back and reported that there was mutual interest and that he had brokered a meeting where we could explore the opportunity. Also, I’ve found in some cases that it is easier to cultivate discussions with an early stage company by working it through a venture partner on their board, than talking directly to the founders. This approach usually applies when the entrepreneur is focused so intensely on the uniqueness of their specific technology, they experience difficulty getting a broader perspective on the value of their product.

Those who have been in the venture capital business for a long time have a tremendous wealth of experience available to their partners. When presenting to our board of directors, I really value the feedback from our own venture partners. They always spot significant issues right away and offer great perspective. Their suggestions are based on similar experiences drawn from many years of deal making.

Lastly, the stereotype of the silicon valley VC is that they are aware of (and know everything about) all the potential deals in the works. Well, it’s true – at least for the really established VC’s. I spoke on a Garage Venture panel discussion on Business Intelligence a year and a half ago. The moderator posed a question to the panel asking for predictions on future M&A announcements. I happened to be sitting next to representatives from Brio and Hyperion (this panel discussion took place prior to Hyperion’s acquisition of Brio). Just to bring some levity to the discussion, I whimsically proposed that Brio would be a great fit for Hyperion. The resulting laughter from the audience was a sure-fire indication that many of the venture partners in attendance knew this deal was far along. Steve Jurvetson even came up to me after the event and confirmed it.

I am not suggesting that the term “vulture capitalist” is entirely undeserved. However, I think entrepreneurs that shut them out completely are doing themselves a disservice. There are many benefits to doing business with the right venture capital partners. And it’s not just about the funding. I’ve found plenty of value in the intangibles. You just have to remember to take advantage of the benefits that venture partners have to offer.

Friday, February 11, 2005

Product Management , the Secret Sauce

I read an interesting post in Ed Sim’s VC blog. He encouraged startups to invest early on in good product management. The comment touched off a number of thoughts and observations I've accumulated over the years. Everyone says they need good Product Management. But how many can actually define the precise characteristics that make a great Product Manager? I’ve found that most people define the role by simply listing various responsibilities – authoring MRDs/PRDs, defining use cases, gathering requirements, etc. If it were only that simple. I’ve witnessed many a product manager execute brilliantly in each of these responsibilities, yet struggle to bring their product to market. It certainly begs the question – “what separates successful product managers from unsuccessful ones?” I believe that the characteristics that define success transcend the skills necessary to execute on these deliverables. Product Management is much more than just writing MRD's and gathering requirements.

A while ago, I was asked to speak to the SVPMA, a local group of Product Managers and Product Marketing managers. The topic was Leadership in Product Management. If a product manager gets lost in simply turning in their deliverables, yet fails to exhibit adequate leadership, they will not be successful. Specifically applied to this role, the notion of leadership is largely derived from a product manager's ability to positively influence all the product stakeholders – executive management, engineering, marketing, and sales (to name the common ones). How can a Product Manager garner the political capital to do this? One solution I’ve seen is to simply have most of these cross functional contributors report directly to the Product Manager. What’s very common in Enterprise Software, however, is to give the Product Manager all the responsibility for the product, yet none of the authority to manage the cross functional team members. There is no doubt this is an extremely difficult challenge to undertake. However, the resulting situation is a crucible that can refine incredibly valuable leadership skills.

Recently, I participated as a panelist for a Norcal PDMA event. Based on the audience Q&A, many in this role are hard pressed with the day-to-day challenges and are eager to cultivate leadership skills. There are two things I always try to impress upon product managers. The first is to cultivate a reputation at your company for having the most knowledge about your product, your customers and your market. In any one area, there may be those who are more knowledgeable. However, the Product Manager must be the most knowledgeable regarding all three simultaneously. The Product Manager must understand and communicate the dynamics between these three areas. Engineers will listen eagerly to the Product Manager who rattles off anecdote after anecdote of real customers and the problems they wish to solve using the product. Executive management will eagerly listen to the Product Manager who explains very clearly where the product is differentiated and also where it is deficient relative to other choices in the market. Developing this type of credibility gives the Product Manager the necessary leverage to get things done. However, they need to go one step further. They cannot make the mistake of establishing credibility and not utilizing their clout to make decisions.

Things brings me to the second thing I try to impress upon product managers. They need to demonstrate a backbone for decision making. I’ve interviewed many candidates, fresh out of business school, who have a very difficult time making hard decisions. These candidates are extremely intelligent, and are very familiar with the classic product development cycle. However, when I ask them a simple question that has no perfect answer, they get extremely flustered. Perhaps we are programmed to look only for tidy solutions. In the real world of enterprise software development, a product manager earns respect by being able to make tough decisions when there is incomplete data and non-ideal choices for outcomes.

The big irony in all this is that Product Managers who are able to demonstrate this level of leadership eventually choose not to stay in Product Management. Their leadership skills provide opportunities with much higher visibility and much greater reward.