Leveling up a product organization

Too many product teams are stuck in a mish-mash of waterfall and agile. And even amongst agile dev teams, it is time they leveled up from agile 1.0.

A waterfall/agile mish-mash is where the dev team attempts to be agile, but the business thinks in waterfall terms with feature roadmaps, time-based estimates, and time-based deadlines.

What do I mean by Agile 1.0? Agile 1.0 is all about production, i.e. shipping features in an effective manner. In Agile 1.0, the stakeholder is called the “customer” (which is crazy when you think about it). In Agile 1.0, dev is too often an order-taker, not a strategic partner in the business.

Using metrics to determine whether a shipped feature is succeeding is important, but that’s only part of the battle. The real mental shift for older organizations comes with incorporating experiments and MVPs into their thought process and product activities. It is hard to do, and I have to push myself constantly to do it better.

It’s not about shipping features. It’s about creating value.

It’s not about meeting deadlines. It’s about delivering real value as quickly as possible.

Your team’s goal (aligned across product management, UX, and development) should not be to ship X-feature by Y-date. Your team’s goal should be to hit X customers as quickly as possible, or raise the conversion rate to X% as quickly as possible, or reduce customer support calls by X amount as quickly as possible. The imperative moves off of shipping ivory-tower features to deeply understanding and then creatively solving problems. It’s still about execution, but smarter execution.

But what about marketing, some might protest: “Marketing needs deadlines!” My response is this: marketing is indeed still critical, but it has changed. You can’t brute force products anymore with marketing. You need the product to be right first, and that cannot be predicted very well, so marketing needs to learn how to be flexible and marketing and product need to communicate closely.

The key question is, can you make room in your process for experiments and MVPs?

Experiments:
For every feature initiative you have in mind, what lightweight experiments can be run to:
1. validate our belief in the initiative
2. inform our knowledge of the problem and customer so that our actual product is better out of the gate

(for example, before building a feature, try adding a button to see if anyone clicks on it, and while you are doing that, do qualitative UX research with real customers. Note: it’s really hard to do experiments unless you are live in the market, even if under a “labs” label; it also would be helpful to invest in A/B test infrastructure)

MVPs:
Every feature idea is a hypothesis that doing A will deliver B in value. But chances are high that you can start delivering value with a little “a” as you iterate to the big “A”. Just keep in mind the actual words in the acronym: minimum, viable, product. Each one is important.

So how do you convert an organization that prioritizes features and deadlines to one that prioritizes value creation?

Next week I’m going to lay out some detailed tactics that might be helpful in doing exactly that.

  • I do see the issue with Agile development being more about “order taking” for a more waterfall-minded business.  This isn’t really anyone’s fault, it’s what it was designed for.

    But I don’t think it’s a big company problem, I think it’s hard-wired into the human psyche (trying to predict the future with our big brains).  Future of our success, future of revenue growth, future of the product, all neatly packaged with timelines, dates, and min and max ranges.

    So what makes it hard to follow a rigid hypothesis-experiment-adapt model is exactly that – we want to predict the future, then rush ahead and manifest it instead of following the steps to validate our predictions step by step.  

    Curious if you’ve got some hacks to work around our (sometimes unconscious) need to predict.

    • Yes, it’s hard to balance love and confidence in a vision (which is important) with ruthless questioning and doubt. My current hypothesis is that it can be broken down by building trust and moving from opinions to data. It also often starts with small wins. I look at Meetup.com, which started with Andres Glusman trying out lean ideas on the side and so much good stuff was coming out of it that they’ve whole-heartedly embraced it in the organization.

  • n_evans

    Thanks for sharing these insights. I’m curious about two things. Why is it hard to run experents without being live in the market and what have you done pre-live to experiment. I’d love to hear some examples of what you’ve tried, what works, and what doesn’t work.

    Thanks,
    Nicholas
    @n_evans on twitter

    • Partly I phrased it that way to push people to get live. You can and should and must do experiments right from the get-go, when something is just a nugget of an idea in your mind. However, all of those experiments give you clues. Necessary clues that can prevent a lot of mistakes and false directions, but still clues. Being live is the ultimate truth. Iterating while being live gives you more discipline, more reality, and more truth about whether you are truly making progress.

      My pre-launch experiments vary depending on what I am doing. You can manually “concierge” your software or product before actually building it. You can try smoke tests with landing pages or videos. You can run qualitative sessions with users with paper or clickable prototypes. You can try pre-selling your product. You also need to think about *who* you are doing your experiments with.  I’ve done all of the above, and the efficacy has very much depending on the type of idea and market.

      but there’s nothing like being live.