Category Archives: Product Strategy

Product Power Breakfast #3: Mark Bauer on Product Management in Early vs. Late-Stage Companies, Working with Offshore Development, and What Makes for PM Success

Join Thomas Otter and me for Product Power Breakfast #3 this Thursday, April 8th at 8am on Clubhouse.

Our special guest is Mark Bauer, a career product leader who started on the end-user side as a business planner at Pepsi, flipped to the vendor side at OLAP category creator Arbor Software, which was acquired by Hyperion Solutions which in turn was acquired by Oracle, and then quit a perfectly good job at Oracle to do it all over again as one of the earliest employees at Host Analytics.

In the middle of Mark’s tenure at Host, he took a sabbatical to lead a non-profit (LaunchCode) which provides free education to help people launch their careers in technology.

So Mark really has  done it all:  from Pepsi to Oracle, from behemoths to ten-person startups, from category leaders to category creators, from corporates to non-profits, Mark’s been there and done that.

In this episode, Dave and Thomas will talk to Mark about topics including:

  • What makes for success in product management?
  • Scaling an organization with proper PM ratios
  • The biggest differences between PM at small and large companies
  • Working effectively with offshore development and PM teams
  • Difference he’s seen in PM across different countries (e.g., US, India, Israel, UK)
  • How to best serve the constituents of PM?
  • Inbound vs. outbound PM?
  • Maybe we’ll even sneak in a conversation about technical debt

I look forward to seeing you there!

Quick Takeaways from Product Power Breakfast #2

Thanks to those who joined us for the second session in our enterprise SaaS Product Power Breakfast series, Thursdays at 8AM.  The link to our third session is here.

Takeaways:

  • Dave shouldn’t use airpods (and won’t henceforth).  And we need to follow mute/unmute protocol better as these devices pick up the slightest noise and jam the audio of the speaker.
  • We covered what I see as the number one risk in product management as expressed by the all too frequent epitaph:  “they weren’t strategic.”  That is, in their quest to keep everyone happy too many PM leaders end up steadily advancing in small increments across a broad front.  In their effort to keep everyone happy, they make no one happy.
  • We discussed the bicycle wheel problem in PM:  the PM sits at the center of a wheel with lots of spokes and hardest part of the job is managing the pull from each of them.  Spokes, e.g., include:  sales/AEs, sales/SEs, product marketing, analyst relations, customer success, customer support, professional services, existing customers, prospective customers, the CTO, engineering (e.g., technical debt), and more.
  • We had a great discussion of technical debt and types of it:  platform-driven (e.g., built on an outdated one), shortcut-driven (e.g., deliberately took shortcuts), architectural (e.g., designed it the wrong way, overlooked redundancy), and execution-driven (e.g., wrote bad code).
  • We touched on the notion of internal platform, a topic worth a session in its own right.
  • We discussed technical debt vs. legacy code.  (See this for a great discussion of the latter.)  We discussed legacy org vs. legacy code (i.e., with a legacy org there’s little point in refactoring legacy code as you’re likely to repeat the same mistakes).
  • We touched on Trust Releases as a great strategy for managing technical debt, and the role of architects in them.
  • We talked a bit about the challenges involved in adding a second product — a topic large enough to warrant a future session on the transition and associated pitfalls, or as Thomas calls it, the (perilous) second album problem.
  • We discussed the difference between existing core product, new potential core product and bright shiny object (BSO) product/features designed to keep the company at the front of the industry conversation.
  • We discussed strategic vs. opportunistic customers and the CEO’s ability to force sales to “sell what’s on the truck,” particularly to opportunistic customers — if it’s a clearly expressed and enforced ground rule.
  • We (barely) touched on the concept of “holistic PM” and why/how PMs should avoid becoming feature addicts and think of themselves more as GMs, even if the company is years away from having an actual GM structure.

We hope to see you on session 3, Thursday, April 8th, and 8AM Pacific.

Quick Takeaways from Product Power Breakfast #1: Dave Interviews Thomas

Here’s a quick post to share my takeaways from our first enterprise SaaS Product Power Breakfast on Clubhouse.

My Thoughts
Clubhouse is definitely a new medium.  When it comes to new media, I always think two things:

  • The medium is the message and all that Marshall McLuhan’s pithy quote implies.
  • Look for differences, not similarities.  (Saying “Clubhouse is like talk radio” is the same as saying “Twitter is like group text messaging.”  Yes and no, but mostly no.)

Special guest Jason Lemkin was a Tasmanian Devil who — while he blew up my carefully planned structure (think: Eisenhower on planning) — left in his wake a slew of super interesting questions; I literally didn’t sleep well that evening because my head was still spinning.  

Thus, overall I’d give the session an A for thought-provocation and a C for structure.  But we’re new to the medium, trying to figure it out, and serendipity is definitely part of the equation.

Questions Provoked, Topics for Future Discussion

  • To what extent should we talk to startups and founders versus large enterprise product managers (PMs)?
  • How valid is commonality-spotting across unicorns (the spotting is subjective and are the commonalities valid drivers or rabbit’s feet)?
  • The age-old question of how to measure engineering productivity?  Can it even be done?  Is it worth trying?
  • Are story points a valid productivity measure or are they counting angels on pinheads?
  • How can PM avoid being drawn and quartered?  (And how can PM avoid drawing and quartering engineering?)
  • Is product-led growth (PLG) a strategy that must be taken in entirety or can you take a dab of this and that?
  • How can PM best make its voice heard and best work with sales?
  • How to cater between the trend-seeking “new black” and the lasting-principles-seeking crowd (e.g., Crystal Reports was the original PLG company in my curmudgeonly humble opinion)?

In terms of session focus, I’d say my current conclusion is that we want to make each session follow this sort of template:  Dave & Thomas Interview {Guest} on {Topic}.

Oh, and by the way, we probably need to re-run a session where Dave actually interviews Thomas!

See you Thursday at 8 am for session number 2!  If you need a Clubhouse invite, email or message me.

Product Power Breakfast #2: Thomas Interviews Dave

(TLDR — Link to Episode #2, Thursday, April 1st at 8 am pacific.)

Well, we just finished the first episode (“Dave interviews Thomas“) of our Enterprise SaaS Product Power Breakfast series and wow, was it crazy.  In addition to our regularly scheduled interview on product management with Thomas, we had:

  • A guest appearance from the ever-brilliant Jason Lemkin, EchoSign founder, VC, and creator of SaaStr — thanks for coming!
  • A surprise cameo from Dharmesh Shah, cofounder and CTO of HubSpot (who I think Jason pulled up [1]) — thanks for coming!

While it was definitely a romp in terms of structure (or lack thereof), it was high energy, full of great content, and fun.

So, we’re going to try it again next week with Episode #2:  Thomas Interviews Dave. Topics on the agenda include:  product management, product strategy, product positioning, and product roadmaps.

Maybe he can control the room better than I did.  See you there!

# # #

Notes

[1] I was following the “it can’t be that Dharmesh” and the “let celebrities be audience members in peace” principles.

 

Ground Rules for our Clubhouse Product Power Breakfasts

As recently announced, Thomas Otter and I are starting what we hope will be a series of Clubhouse Enterprise SaaS Product Power Breakfasts, Thursdays at 8 AM Pacific time.  The link to the first one is here and the Slido Q&A is here.

In order to keep things flowing smoothly, and in response to my experience on Clubhouse thus far, I started writing a ground rules document for Thomas and me, but decided it could be useful for everyone who joins us — particularly because I’m suspecting many of us are pretty new to Clubhouse.  So here goes.

Moderators

  • Keep the room on topic = enterprise SaaS product.
  • No soliloquies = back and forth makes Clubhouse interesting.
  • Let other moderators talk. (Hint:  we’re all type A.)
  • Answer the question for the room, not just to the person.
  • Answer the question you thought you were asked.  (So audience please make questions clear!)  We want to avoid triple restatements, which are sadly fairly common –> The question is X.  Was your question X?  Yes, my question was X.
  • Go on mute when you’re not speaking (particularly if you see the grey outline flickering; it means you’re picking up noise)
  • Come off mute to indicate that you want to speak
  • Flash mute on and off to “clap” when someone else is speaking
  • By default, avoid what I’ll call Clubhouse Verbose Protocol (e.g., “Hi, this is Dave speaking, the answer to your question is no, this is Dave and I am done speaking.) [1] [2].

Those Moved Up to Stage

  • Ask your question clearly as possible.
  • Do a brief, one-line self introduction (e.g., “my name is Dave, I’m a PM at Zendesk, and my question is …”)
  • Please try to keep questions reasonably brief and of general interest.
  • Don’t be bothered if we put you back to the audience after your question.  We’re just tidy.
  • No self or company promotions please (i.e., please don’t try to use this forum as a way to market your goods or services).

Audience Members

  • Ping people into the room if you’re enjoying the content!
  • Raise your hand to ask a question; we love questions.
  • Use Slido to ask questions as well.  The event code for our first event is 569975.
  • Please fill in your bio so we know who you are.
  • Mute your phone when you’re moved up on stage (bottom right of screen); it’s not muted by default.
  • We’ll try to answer all questions from those we pull up on stage; if we’re near the end of the session, please be sensitive to that as we want to end on time.
  • We reserve the right to promote special guests and bring them up on stage out of order.
  • While we have not (yet perhaps) created a club and ergo have no Club Rules, normal rules of business and social media decorum apply.
  • I’ve had requests to record these sessions and make them available in other media (e.g., podcasts) but have not figured out how to do that yet.  Once we’re not total noobs on Clubhouse, we’ll explore doing so, in accordance with Clubhouse norms.

# # #

Notes

[1] Typically used in my experience in rooms with a large number of moderators and/or people on stage.

[2]  We will do so by request if members of the audience desire it, for any reason, in order to better follow the conversation.  For example, visually challenged people sometimes request this, particularly if all the speakers have similar voices and/or accents.  In our case, Dave has a New York accent (and accompanying pace) muddled by years of living in California.  Thomas has a South African accent, perhaps muddled by years of living in Germany.

SaaS Product Power Breakfasts, Thursdays at 8 AM Pacific on Clubhouse

Interested in all things product?

Then please join me and my friend and esteemed colleague Thomas Otter on Thursday mornings at 8 am pacific for what we’re hoping will become a series of Enterprise SaaS Product Power Breakfasts where we will talk among ourselves, with invited guests, and with the audience about all things product, including:

  • Product management
  • Product strategy
  • Product marketing
  • Product design
  • Product positioning
  • Product roadmaps
  • Product requirements (to generalize or not to generalize)
  • Application / platform dynamics
  • Product input and feedback processes
  • Pricing strategies
  • Product portfolios
  • Product-led growth
  • Managing new vs. existing products
  • The transition from 1 to N products
  • Product development processes (e.g., agile, scrum)
  • Minimum viable product
  • Managing product managers
  • The transition to general manager (GM)
  • And much more

For those on Clubhouse, here’s a link to the event.  If you’ve not tried Clubhouse yet, well here’s a great reason to join — ask a friend for an invite if you need one.  In a real pinch, ask me or Thomas via DM on Twitter (we each have a few).

My interest in product stems from my overall fascination with strategy and my experience in product marketing at Ingres (RDBMS), CMO at Versant (ODBMS) and Business Objects (BI/analytics), SVP/GM at Salesforce.com (Service Cloud), and CEO at MarkLogic (NoSQL) and Host Analytics (Planning).  That’s not to mention lesser involvement in strategy working in board and/or advisory mode at companies including Aster Data (NoSQL), Nuxeo (ECM/DAM), and Alation (data intelligence).

Thomas’ interest in product stems from his infinite curiosity about the intersection between technology and people.  Thomas was part of the leadership team that scaled SuccessFactors to over 50M end users, managing not only product but literally scores of product managers.  Prior to that Thomas was an analyst at Gartner where he drove the HRTECH research agenda that helped shape the industry.  Truly a multidisciplinary thinker, Thomas’ PhD dissertation “sits awkwardly at the intersection of IT, law, and business.”  He’s thus a heck of an interesting guy to talk to.

See you there!

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.