Category Archives: Business Objects

What is a Minimum Viable Product, Anyway? My Favorite MVP Analogy.

The concept of minimum viable product (MVP) has been popularized in the past decade thanks to the success of the wonderful book, The Lean Startup.  It’s thrown around so casually, and you hear it so often, that sometimes you wonder how — or even if — people define it.

In this post, I’ll describe how I think about MVPs, first using one real-life example and then using my favorite MVP analogy.

The concept of a minimum viable product is simple:

  • Every startup is basically a hypothesis (e.g., we think people will buy an X).
  • Instead of doing a big build-up during a lengthy stealth phase concluding in a triumphant (if often ill-fated) product unveiling, let’s build and ship something basic quickly — and start iterating.
  • By taking this lean approach we can test our hypothesis, learn, and iterate more quickly — and avoid tons of work and waste in the process.

The trick is, of course, those two pesky words, minimum and viable.  In my worldview:

  • Minimum means the least you can do to test your hypothesis.
  • Viable means the product actually does the thing it’s supposed to do, even in some very basic way.

I’ll use an old, but concrete, example of an MVP from my career at Business Objects.  It’s the late 1990s.  The Internet is transforming computing.  We sell a high-functionality query & reporting tool, capable of everything from ad hoc query to complex, highly-formatted reports to interactive multidimensional analysis.  That tool is a client/server Windows application and we need to figure out our web strategy.  We are highly constrained technologically, because it’s still the early days of the web browser (e.g., browsers had no print functionality) [1].

After much controversy, John Ball and the WebIntelligence team agreed on (what we’d now call) the following MVP:

  • A catalog of reports that users can open/browse
  • End-user ad hoc query
  • Production of very basic tabular reports
  • Semi-compatibility with our existing product [2]

But it would work in a browser without any plug-ins, web native.  No multi-block reports.  No pages.  No printing.  No interactive analysis.  No multidimensional analysis.  No charting.  No cross-tabs.  No headers, no footers.  Effectively, the world’s most basic reporting tool — but it let users run an ad hoc query over the web and produce a simple report.  That was the MVP.  That was the hypothesis — that people would want to buy that and evolve with us over time.

Because of that tightly focused MVP we were able to build the product quickly, position it clearly within the product line [3], and eventually use it as the basis for an entirely new line of business [4].

Now, let’s do the analogy.  Pretend for a moment we’re in a world where there are no four-wheel drive cars.  We have invented the four-wheel drive car.  We imagine numerous use-cases [5] and a big total available market (TAM).

What should be our MVP?  Meet the 1947 Jeep Willys [6] [7].

No roof.  No back seat.  In some cases, no windscreen.  No doors.  No air conditioning.  No entertainment system.  No navigation.  No cup holders.  No leather.  No cruise control.  No rearview camera.  No ABS.  No seatbelts.  No airbags.

No <all that shit that too many product managers say are requirements because they don’t understand what MVP means>.

Just the core:  a seat, a steering wheel, an engine, a transmission, a clutch, and four traction tires.

  • Is it missing all kinds of functionality?  Yes
  • In this case, would it even be legal to sell?  No.  Well, maybe off-road, but we’re in analogy-mode here.
  • But can it get you across a muddy field or down a muddy road?  YES.

And that’s the point.  It’s minimum because it’s missing all kinds of things we can easily imagine people wanting, later.  It’s viable because it does the one thing that no other car does.  So if you need to cross a muddy field or go down a muddy road, you’ll buy one.

As Steve Blank says:  “You’re selling the vision and delivering the minimum feature set to visionaries, not everyone” [8]. 

So next time you think someone is focused on jamming common but non-core attributes into an MVP, tell them they’re counting cupholders in a Willys and point them here.

# # #

Notes

[1] And printing is a pretty core requirement for a reporting application!

[2] This was key.  WebIntelligence could not even open a BusinessObjects report.  Instead, we opted for compatibility one layer deeper, at the semantic layer (that defined data objects and security) not the reporting layer.

[3] If you want all that power, use BusinessObjects.  If you want web native, use WebIntelligence.  And you can share semantic layer definitions and security.

[4] BI extranets.

[5] From military off-road applications to emergency off-road and/or slippery conditions to sand recreational to family vehicles on snow and many  more.

[6] Which in some ways literally was the MVP for Jeeps.

[7] Popularized by the Grateful Dead in Sugar Magnolia (“… jump like a Willys in four-wheel drive.”)

[8] Where I’ll define visionary as someone who has the problem we’re trying to solve and willing to use a new technology to solve it.  It’s a little easier to think of someone trying a next-generation database system as a “technology visionary” than the Army buying a Jeep, but it’s the same characteristic.  They need a currently unsolvable problem solved, and are willing to try unconventional solutions to do it.

An Epitaph for Intrapreneurship

About twenty years ago, before I ran two startups as CEO and served as product-line general manager, I went through an intrapreneurship phase, where I was convinced that big companies should try to act like startups.  It was a fairly popular concept at the time.

Heck, we even decided to try the idea at Business Objects, launching a new analytical applications division called Ithena, with a mission to build CRM analytical applications on top of our platform.  We made a lot of mistakes with Ithena, which was the beginning of the end of my infatuation with the concept:

  • We staffed it with the wrong people.  Instead of hiring experts in CRM, we staffed it largely with experts in BI platforms.  Applications businesses are first and foremost about domain expertise.
  • They built the wrong thing.  Lacking CRM knowledge, they invested in building platform extensions that would be useful if one day you wanted to build a CRM analytical app.  From a procrastination viewpoint, it felt like a middle school dance.  Later, in Ithena’s wreckage, I found one of the prouder moments of my marketing career  — when I simply repositioned the product to what it was (versus what we wanted it to be), sales took off.
  • We blew the model.  They were both too close and too far.  They were in the same building, staffed largely with former parent-company employees, and they kept stock options in both the parent the spin-out.  It didn’t end up a new, different company.  It ended up a cool kids area within the existing one.
  • We created channel conflict with ourselves.  Exacerbated by the the thinness of the app, customers had trouble telling the app from the platform.  We’d have platform salesreps saying “just build the app yourself” and apps salesreps saying that you couldn’t.
  • They didn’t act like entrepreneurs.  They ran the place like big-company, process-oriented people, not scrappy entrepreneurs fighting for food to get through the week.  Favorite example:  they had hired a full-time director of salesops before they had any customers.  Great from an MBO achievement perspective (“check”).  But a full-time employee without any orders to book or sales to analyze?  Say what you will, but that would never happen at a startup.

As somebody who started out pretty enthralled with intrapreneurship, I ended up pretty jaded on it.

I was talking to a vendor about these topics the other day, and all these memories came back.  So I did quick bit of Googling to find out what happened to that intrapreneurship wave.  The answer is not much.

Entrepreneurship crushes intrapreneurship in Google Trends.  Just for fun, I added SPACs to see their relatively popularity.

Here’s my brief epitaph for intrapreneurship.  It didn’t work because:

  • Intrapreneurs are basically entrepreneurs without commitment.  And commitment, that burn the ships attitude, is key part of willing a startup into success.
  • The entry barriers to entrepreneurship, particularly in technology, are low.  It’s not that hard (provided you can dodge Silicon Valley’s sexism, ageism, and other undesirable -isms) for someone in love with an idea to quit their job, raise capital, and start a company.
  • The intrapreneurial venture is unable to prioritize its needs over those of the parent.  “As long as you’re living in my house, you’ll do things my way,” might work for parenting (and it doesn’t) but it definitely does not work for startup businesses.
  • With entrepreneurship one “yes” enables an idea, with intrapreneurship, one “no” can kill it.  What’s more, the sheer inertia in moving a decision through the hierarchy could kill an idea or cause a missed opportunity.
  • In terms of the ability to attract talent and raise capital, entrepreneurship beats intrapreneurship hands down.  Particularly today, where the IPO class of 2020 raised a mean of $350M prior to going public.

As one friend put it, it’s easy with intrapreneurship to end up with all the downsides of both models.  Better to be “all in” and redefine the new initiative into your corporate self image, or “all out” and spin it out as an independent entity.

I’m all for general mangers (GMs) acting as mini-CEOs, running products as a portfolio of businesses.  But that job, and it’s a hard one, is simply not the same as what entrepreneurs do in creating new ventures.  It’s not even close.

The intrapreneur is dead, long live the GM.

My Appearance on DisrupTV Episode 100

Last week I sat down with interviewers Doug Henschen, Vala Afshar, and a bit of Ray Wang (live from a 777 taxiing en route to Tokyo) to participate in Episode 100 of DisrupTV along with fellow guests DataStax CEO Billy Bosworth and big data / science recruiter Virginia Backaitis.

We covered a full gamut of topics, including:

  • The impact of artificial intelligence (AI) and machine learning (ML) on the enterprise performance management (EPM) market.
  • Why I joined Host Analytics some 5 years ago.
  • What it’s like competing with Oracle … for basically your entire career.
  • What it’s like selling enterprise software both upwind and downwind.
  • How I ended up on the board of Alation and what I like about data catalogs.
  • What I learned working at Salesforce (hint:  shoshin)
  • Other lessons from BusinessObjects, MarkLogic, and even Ingres.

DisrupTV Episode 100, Featuring Dave Kellogg, Billy Bosworth, Virginia Backaitis from Constellation Research on Vimeo.

 

Why has Standalone Cloud BI been such a Tough Slog?

I remember when I left Business Objects back in 2004 that it was early days in the cloud.  We were using Salesforce internally (and one of their larger customers at the time) so I was familiar with and a proponent of cloud-based applications, but never felt great about BI in the cloud.  Despite that, Business Objects and others were aggressively ramping on-demand offerings all of which amounted to pretty much nothing a few years later.

Startups were launched, too.  Specifically, I remember:

  • Birst, née Success Metrics, and founded in 2004 by Siebel BI veterans Brad Peters and Paul Staelin, which was originally supposed to be vertical industry analytic applications.
  • LucidEra, founded in 2005 by Salesforce and Siebel veteran Ken Rudin (et alia) whose original mission was to be to BI what Salesforce was to CRM.
  • PivotLink, which did their series A in 2007 (but was founded in 1998), positioned as on-demand BI and later moved into more vertically focused apps in retail.
  • GoodData, founded in 2007 by serial entrepreneur Roman Stanek, which early on focused on SaaS embedded BI and later moved to more of a high-end enterprise positioning.

These were great people — Brad, Ken, Roman, and others were brilliant, well educated veterans who knew the software business and their market space.

These were great investors — names like Andreessen Horowitz, Benchmark, Emergence, Matrix, Sequoia, StarVest, and Tenaya invested over $300M in those four companies alone.

This was theoretically a great, straightforward cloud-transformation play of a $10B+ market, a la Siebel to Salesforce.

But of the four companies named above only GoodData is doing well and still in the fight (with a high-end enterprise platform strategy that bears little resemblance to a straight cloud transformation play) and the three others all came to uneventful exits:

So, what the hell happened?

Meantime, recall that Tableau, founded in 2003, and armed in its early years with a measly $15M in venture capital, and with an exclusively on-premises business model, literally blew by all the cloud BI vendors, going public in May 2013 and despite the stock being cut by more than half since its July 2015 peak is still worth $4.2B today.

I can’t claim to have the definitive answer to the question I’ve posed in the title.  In the early days I thought it was related to technical issues like trust/security, trust/scale, and the complexities of cloud-based data integration.  But those aren’t issues today.  For a while back in the day I thought maybe the cloud was great for applications, but perhaps not for platforms or infrastructure.  While SaaS was the first cloud category to take off, we’ve obviously seen enormous success with both platforms (PaaS) and infrastructure (IaaS) in the cloud, so that can’t be it.

While some analysts lump EPM under BI, cloud-based EPM has not had similar troubles.  At Host, and our top competitors, we have never struggled with focus or positioning and we are all basically running slightly different variations on the standard cloud transformation play.  I’ve always believed that lumping EPM under BI is a mistake because while they use similar technologies, they are sold to different buyers (IT vs. finance) and the value proposition is totally different (tool vs. application).  While there’s plenty of technology in EPM, it is an applications play — you can’t sell it or implement it without domain knowledge in finance, sales, marketing or whatever domain for which you’re building the planning system.  So I’m not troubled to explain why cloud EPM hasn’t been a slog while cloud BI absolutely has been.

My latest belief is that the business model wasn’t the problem in BI.  The technology was.  Cloud transformation plays are all about business model transformation.  On-premises applications business models were badly broken:  the software cost $10s of millions to buy and $10s of millions more to implement (for large customers).  SMBs were often locked out of the market because they couldn’t afford the ante.  ERP and CRM were exposed because of this and the market wanted and needed a business model transformation.

With BI, I believe, the business model just wasn’t the problem.  By comparison to ERP and CRM, it was fraction of the cost to buy and implement.  A modest BusinessObjects license might have cost $150K and less than that to implement.  That problem was not that BI business model was broken, it was that the technology never delivered on the democratization promise that it made.  Despite shouting “BI for the masses” in 1995, BI never really made it beyond the analyst’s desk.

Just as RDBMS themselves failed to deliver information democracy with SQL (which, believe it or not, was part of the original pitch — end users could write SQL to answer their own queries!), BI tools — while they helped enable analysts — largely failed to help Joe User.  They weren’t easy enough to use.  They lacked information discovery.  They lacked, importantly, easy-yet-powerful visualization.

That’s why Tableau, and to a lesser extent Qlik, prospered while the cloud BI vendors struggled.  (It’s also why I find it profoundly ironic that Tableau is now in a massive rush to “go cloud” today.)  It’s also one reason why the world now needs companies like Alation — the information democracy brought by Tableau has turned into information anarchy and companies like Alation help rein that back in (see disclaimers).

So, I think that cloud BI proved to be such a slog because the cloud BI vendors solved the wrong problem. They fixed a business model that wasn’t fundamentally broken, all while missing the ease of use, data discovery, and visualization power that both required the horsepower of on-premises software and solved the real problems the users faced.

I suspect it’s simply another great, if simple, lesson is solving your customer’s problem.

Feel free to weigh in on this one as I know we have a lot of BI experts in the readership.

Slides from My Presentation at the Plug and Play Tech Center Collaboration Event

Yesterday I spoke on a panel of international software companies at the Plug and Play Tech Center’s Acceleration and Collaboration Track event in Sunnyvale, California.

I was invited not to discuss Mark Logic’s success (we are a US-based company), but to discuss my experience prior to Mark Logic as a key member of the executive team that grew Paris-based Business Objects from around $30M to more than $850M during my nine years there.

Other panelists included:

  • Marten Mickos, CEO of MySQL (now SVP of the database group at Sun Microsystems), a company originally founded in Sweden and Finland
  • Eyal Hertzog, co-founder of video site Metacafe, a company founded in Israel
  • Kurt Hemecker, SVP of business development at Echovox, a company founded in Switzerland

Here are the slides from my presentation on the panel.