product management

There are 4 posts filed in product management (this is page 1 of 1).

THE best conference for UX/Design managers and leaders…

…is Adaptive Path’s MX Conference, taking place on March 29-30 2016 in San Francisco.

I’m biased. After a few years away, I’m back and helping program and host this year’s event. We have a stellar line-up, including Bob Baxley (formerly Apple and Pinterest), Hyo Yeon (leading the design charge at McKinsey), Janaki Kumar (VP Design at SAP), Kim Scott (spreading the gospel of Radical Candor, a philosophy I can totally get behind), and many others. Oh, and me (I’ll be co-teaching, with Kristin Skinner, a workshop on “Org Design for Design Orgs”, based on what we’ve been writing in our book).

No other conference packs so much value into two days for folks who are managing/directing/leading design teams.

AND: Use the promotional code FOPM to get 15% off the registration price!

The dehumanizing heart of capitalism – people as points in a video game

For 5 months last year, I contracted with a company launch a new web site.

My task was to shepherd the design (which was completed before I joined) through development and into the world. As such, in my duties I was a product manager, coordinating efforts with engineering, design, and marketing, making sure that the new design performed as well as the old one.

In order to understand performance, I spent much of my time analyzing charts and graphs, assessing conversion rates and looking for clues across browsers, operating systems, and flows to understand why one design was performing better than another.

And it was in this activity that I started to scare myself. Because I became obsessed with conversion numbers. How do we make sure that at least the same number of people move through the new design as the old one?

And it started to feel like a game. These conversion metrics are points. If you fiddled with some aspect of the design, could you get a higher score? And as anyone raised in video games knows, you are always trying to get a high score.

It’s very easy to forget that there are humans in those numbers. You approach it more like an amorphous mass, a fluid that you’re trying to get through a funnel.

A key theme of my writings about the Connected Age was the need for business to embrace humanity. And yet even though I am highly sensitized to this issue, it was seductively easy to slip into this dehumanizing mindset.

This is at the heart of capitalism.

Design should drive product and engineering, not vice versa

[Note: I’m actually wary of “should”s, and what follows is more of a provocation than a call to arms. But I think it needs to be seriously considered.]

In 2007, Jared Spool wrote about the market maturity framework, and how technical product categories evolve from “technology” (where it’s compelling that a product simply does a thing at all) to “features” (where there’s competition that stakes claims based on the number of capabilities) to “experience” (which delivers a gestalt greater than the sum of the parts, and often involves removing features).

Most technical product organizations are still driven by engineering (“technology”) or product management (“features”). “Experience” is where design comes to the fore, but because of its nascency, design is typically subsumed into an existing engineering- or PM-driven org.

This means that many organizations place design within existing product/feature teams, looking something like this (for an imagined e-commerce service):

typicalprod

The vertical orientation is primary. On the left, there’s a leadership team with a Director of Design, Director of Product, and Director of Engineering who coordinate and plan across the teams. Then you have distinct “feature” teams that own different parts of the product, comprised of a product manager, a designer, and 4 (or so) engineers.

At Groupon, and in some other orgs I know, you see an organization more like this:
centralizedpartnership

The design team is distinct and works together. The Director of Design still coordinates with Director of Product and Director of Engineering, and now also with a Product Manager on a key feature team. We’ve introduced Senior Designers who own relationships with two Product Managers each. When a PM needs to know what’s going on with design, the PM talks to that senior designer. And then we have 2-3 additional designers who collaborate with the Senior Designers or Director of Design as needed.

I call this a “Centralized Partnership” model, where design is centralized, but, through the senior designers, there is a real commitment and partnership with product areas. The benefit of this model is that designers can work across multiple features, ensuring coherence of the experience.

However, this is still ruled by “features”. So, maybe we need to fundamentally rethink it?

If companies are serious about focusing on experience, than design teams should be free to work on that holistic experience, which means that they can actually address a whole lot more. At Adaptive Path, I lead a project team on an e-commerce site. We were able to deliver across many more features, because we weren’t constrained by product teams.

designteam_experience

The open question is to figure out how product management and engineering should be structured to support this crafting of experience. But it doesn’t make sense to let legacy organization structures constrict our ability to deliver the greatest possible experience for our users.

On the shortcomings of “Minimum Viable Product”

Christina Wodtke recently wrote “Getting the V Right”, addressing a common failing of Lean Startup practice — successfully establishing viability in your Minimum Viable Product (MVP). I commented there, but felt it worth expanding here.

The MVP Incantation

My frustration with MVP comes from its reckless use in product management. When launching a feature, I’d hear about “We just need to get our MVP out.” But never was there any attempt at determining viability. What product managers actually meant was, “next release,” but used “MVP” to suggest savvy and greater likelhood to succeed. Christina attempts to address this by coaching people on how to appropriately articulate viability, even resorting to the grade-school-essay canard of the dictionary definition. The problem is, most folks who are misusing MVP are already a lost cause – they’re cargo cultists hoping an incantation gets results, and no amount of guidance will change that core behavior.

Viability is unpredictable

MVP rests on an assumption that you can pre-assess something’s viability with reasonable confidence. However, viability can only be understood in retrospect — you can try to predict it, but really you won’t know until it’s out there. I suspect this is why so many people punt on defining it, in favor of “just get something out and see how people react.” But then this just turns into a resource-wasting exercise in throwing spaghetti, hoping that something sticks.

“MVP” doesn’t galvanize and inspire

However, even if we believe that MVP is an appropriate tool, the confusion in its use suggests a different issue — that while it’s proven catchy enough to spread, it’s nebulousness and abstractness limit its utility. Nebulousness leads to too much variance in how it can be interpreted, and abstractness means it doesn’t galvanize a product team. No one gets excited about launching an MVP. It lacks punch. I much prefer models such as Brandon Schauer’s Cake Model of Product Strategy or Spotify’s vehicular one:

These models communicate what’s most important — that at every stage, even the very first, you must deliver something that feels complete, and delivers useful functionality and/or delight. I’ve personally seen teams shift from MVP to “cupcake,” and, in doing so, shift focus on delivering some bare minimum to something that they can get enthused about.

Maybe we’ve been using the wrong kind of viable?

I teased about the dictionary definition, but there’s actually something in there that’s valuable that I’ve never heard discussed in the context of MVP:

(of a seed or spore) Able to germinate.

We’ve been so focused on economic viability, that we overlooked the origin of the word “viable”, rooted in the word “life.” The common thinking for MVP is “what is the least I can do to deliver a product that doesn’t fail”, but wouldn’t it be more interesting, and inspirational, if we thought, “what can I deliver that could take on a life of its own?”