Ivan Chong: The I-Blog

The Crowd Can Talk Back!

2008-06-22T12:01:00.000-07:00

Informatica's annual customer conference was held a few weeks ago. I've been participating in this event for years. This year was really different because we decided to incorporate the online community into the event. We showed a funny video on mainstage and then posted it on YouTube. We had live blogging and commentary during the conference. After I gave my keynote presentation, I was able to get real-time feedback. After the conference, several attendees "wrote on my wall" in Facebook and commented on my presentation.

Communication with customers used to be entirely episodic. Now, with social-networking, the opportunities exist to blend traditional events (like an annual customer conference) with online forums and communities. As I stand on mainstage during the event, I am no longer talking to an inanimate mass of attendees. The community can now talk back... often in real-time.

Dramatic Effect

2005-11-18T01:15:00.000-08:00

I recently had dinner with one of our board members who has had a remarkable career in marketing. We spent three hours talking about his experiences and he offered some really interesting pieces of advice. One thing he encouraged was the use of a "dramatic effect." The example given was that of the Memorex commercial with the tape recording of the opera singer shattering a glass. The company was branded on the notion of high fidelity. The ad "Is it Live or is it Memorex?" worked to succinctly drive home the notion of fidelity to the consumer. Memorex products were therefore branded with the notion of hi fidelity. The dramatic effect was the shattering of the glass. In consumer goods, marketeers strive to come up with a value proposition so compelling that buyers jump up and down over the perceived benefits.

Is it reasonable to have this notion carry over to enterprise software? Is there such a thing as dramatic effect for this category of product? SAP, the most dominant applications software company in the world, has very lukewarm endorsements from its users. At a recent conference, I listened to a panel of SAP users talk about their experiences with SAP. "We're happy that we have SAP. Implementing SAP was a nightmare, but at least we lived to tell about it..." "We've been successful with SAP, no question. We're scarred from the experience, but hey it's working for us." Obviously, there are lots of examples in enterprise software where success is not correlated with having a raving fan base. The question is -- will this always be the case?

Resistance is NOT Futile

2005-03-20T14:51:00.000-08:00

As you can imagine, the work schedule gets a little hectic the day one of your competitors gets acquired by IBM. Ed Sim's latest blog post "When Competitors Get Acquired" sums up the issues perfectly...

Critical Mass in Silicon Valley

2005-03-01T00:16:00.000-08:00

Recently, I had lunch with a venture partner and we discussed the state of innovation in Silicon Valley, as well as other parts of the world. It's pretty well understood that technology innoviation in Silicon Valley has been driven by several factors -- availability of engineering talent, partnerships between industry and academia, and lastly capital investment infrastructure. These days, such conditions are by no means unique to Silicon Valley. But then that begs the question -- will this area continue to be the fertile crescent valley of innovation? My associate proposed a new element that I'd not heard previously. He posited that Silicon Valley fosters innovation because it inherits the "49er spirit" -- an attitude that holds no tolerance for status quo. The gold-rush settlers came to Northern California because they wanted a better life and this area offered plenty of opportunity. Hence, a cultural attitude developed where it is not only permitted to challenge the status quo, but encouraged. (Think Apple vs. IBM in the 1980's).

To some extent, Silicon Valley culture is a more concentrated form of the immigrant culture for which the US, in general, is known. This reminds me of a quote I read in a recent editorial from a German newspaper.

Europeans today -- just like the Europeans of 1987 -- cannot imagine that the world might change. Maybe we don't want the world to change, because change can, of course, be dangerous. But in a country of immigrants like the United States, one actually pushes for change.

The craving for change and progress is more prevalent in Silicon Valley than in other parts of the US... so far. When added to other factors like engineering talent, academia, and venture capital, there is critical mass for innovation.

Sarbox Impact on Product Roadmaps

2005-02-28T22:14:00.000-08:00

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.

Differentiating Differentiation

2005-02-27T17:16:00.000-08:00

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:

Product Trial (or Proof of Concept)
Demo
Messaging
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.

Some Buy-side Perspective on Venture Partners

2005-02-13T21:55:00.000-08:00

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.

Product Management , the Secret Sauce

2005-02-11T00:48:00.000-08:00

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.

Strategy and Existentialism

2005-01-18T01:49:00.000-08:00

A complaint often heard within the ranks of a struggling technology company is “we have no strategy.” Not surprisingly, if I ask an executive from any of these companies what their company strategy is, they will have an answer. Who’s right? The disgruntled, overworked employees? Or their executives who insist there is a strategy by passionately articulating the details of that strategy? From what I’ve observed, the answer to this question is “it doesn’t matter.”

Whether the strategy is right or wrong, the fact that it is not clearly understood is a huge problem. For all intents and purposes, a strategy that cannot be understood by all the members of an organization is not a strategy at all. My last year in college, I took a class entitled “Strategic Planning” taught by a guest lecturer from GE’s Aircraft Engine division. I’ll never forget a statement he made the first day of class. “Strategy must be simple.” Having spent very little time working in the real world, I could not bring myself to find that statement credible. What’s so challenging about thinking up something simple?

I’ve worked with many incredibly intelligent, articulate individuals who are very uncomfortable proposing simple solutions. It’s not my intention to psychoanalyze this tendency. However, I believe the desire to demonstrate sophistication permeates hi-tech corporate culture. There is also a related tendency to be dismissive of solutions that appear to oversimplify. Having worked six years at Oracle during the early 1990’s, I heard a lot of industry criticism about Oracle’s brash claims to solving business problems. But I never ever heard any employees complain that there was no corporate strategy or no product strategy. Sure, there was endless debate about whether the strategy was correct (in hindsight, it's difficult to rationalize time spent questioning Oracle's strategy). But at least everyone understood the strategy well enough to critique it. While competitors messaged on technology differentiators, Larry Ellison spoke passionately about the need for “client-server” computing to deliver flexibility to the enterprise. Portability (or the ability for the database server to work the same no matter the host hardware platform) was a key differentiator underwriting Oracle’s claim to deliver on client-server computing.

In spite of the general aversion to a simple strategy, there is good reason to embrace it. By forcing the issue on clarity, company strategists set a crisp framework for prioritization. Organizations are made up of many different individuals. They all have different backgrounds, skills, and responsibilities. The technology business requires knowledge mastery over a myriad of details. Complexity already exists. Given this context, how do you get every employee to apply their efforts additively? A complicated strategy will yield varied interpretation throughout the organization. Efforts will inevitably clash, resulting in frustration. Ultimately, sensing that no one else is adhering to “the strategy” individuals will conclude, “there is no strategy.” This can be an extremely demoralizing state of affairs. Sun Tzu wrote “Tactics without strategy is simply noise before defeat.” A simple strategy will yield consistent interpretation throughout the organization. There is greater likelihood for alignment of efforts – this will lead to progress. A simple strategy requires far less effort to coordinate internal resources. As a result, more effort can be applied toward external facing issues – e.g., executing better than the competitors.

If a tree falls in the woods, but no one is around to hear it, is there a noise? I’m not sure I can answer that question. In the high tech business, if a company has a strategy that is not readily understood, does it do any good? I’d have to say “no.”