16
Jun 17

To 10x Your Profits Start With Retrospectives

20% is boring

As many of you know, there’s a technique called a “retrospective” in scrum, or you might call it a debrief. After each sprint the team spends a short amount of time reviewing what went well, what could be improved, and what they should stop doing. The goal is for the team to learn quickly from each sprint.

So, let’s say I really wanted my team to start doing retrospectives, and the team is unwilling. So I share this little bit of research with them:

In a meta-analysis of 46 studies on debriefs (also called after action reviews or lessons learned), Scott Tannenbaum and Christopher Cerasoli found that when appropriately conducted, debriefs can lead to a 20-25% average improvement in performance.  The authors found performance improvements in the use of debriefs with both teams and individuals.  (Thanks to the Center For Evidence Based Management for sharing this study.)

Obviously, based on this data retrospectives and debriefs should be a no-brainer. They are easy and they make your team 20% more effective. But this data still doesn’t motivate most teams to act. Why not?

Because a 20% improvement isn’t enough to get the team to change its behavior.

I need a 10x benefit

This is a general problem for product managers. 20% improvements aren’t interesting to people, whether they’re your customers or your team members. One of my product management rules of thumb is the “Factor of 10 rule” – people aren’t willing to make a change – to a new product, to a new process – unless they get a 10x benefit on a metric they care about.

Back to my problem. I still think retrospectives are a good idea, because I want my team to learn faster. What if I can figure out how to pitch retrospectives as making an order of magnitude difference to something important?

When does 20% equal 10x?

Somehow, I have to make 20% appear to be 1000%.

And that’s what this post is about. (It’s not really about retrospectives.)

Let me tell you one of my favorite stories. At NetIQ we improved the uptime of Windows servers by 20%. That’s nice, but as I said above, it’s not compelling.

But by improving uptime, we also reduced downtime. If you do the math, we reduced it by a factor of nearly 100 – two orders of magnitude! And I can assure you that our customers cared a lot about having less downtime. That’s a story you can tell, and indeed at NetIQ we told that story well.

Can we apply the same kind of thinking to “20% performance improvement?” Somehow turn it into an order of magnitude improvement?

Well, here’s one way. It’s similar to the “downtime/uptime” calculation we did at NetIQ.

Teams improve by learning faster

How fast will the team learn if they don’t do retrospectives? I assume the team’s performance will increase over time naturally, but kind of slowly. Let’s call it 2%. So, if retrospectives increase that rate to 20% … I get a factor of 10x right there.

With this data I can say, “I recommend the team start doing retrospectives – your performance will improve 10x faster.” Retrospectives accelerate the team’s learning, and they accelerate it by a factor of 10. That’s a much better pitch. And learning faster is a benefit that most teams consider important.

How does 10x faster learning affect the bottom line?

But now let’s make the problem a little harder. I don’t just want the team to do retrospectives, which are free. I want the company to buy the team a tool to support retrospectives. And unfortunately, the execs don’t care that much about team learning, no matter what they say about “the company’s people are our most important asset!”

So I have to go to the next step. I need to show a dollars-and-cents business benefit of “improving performance 10x faster.”

What happens when you accelerate your learning by a factor of 10? Well, the whole point of having a higher performing team is to release higher quality products faster.

And what happens when you introduce higher quality products to market faster? You get more revenue faster.

What happens when you get more revenue faster, but with the same team and the same level of effort? All the additional revenue goes straight to the bottom line. So your profit grows, and it grows faster than it would have.

Triple profit for almost no cost

Let’s put some numbers around that. Let’s say that improving the team’s performance results in a 10% improvement in time to market, which results in a 10% improvement in being able to close sales. In any period I get 10% more sales than I would have.

Let’s also assume that our profit margin was 5% before. If I had $10 million in revenue in a quarter, our quarterly profit was $500,000.

With my improved team performance, all the costs are the same, except I’m spending a little bit more on a tool – say that’s $3,000 per quarter. Otherwise, all I’m doing differently is having another short meeting every few weeks. I didn’t add anyone to the team. But now my revenue is $11 million in the quarter because I got better product to market faster. My profit is now $1,497,000.

Improving the team’s performance by 20% resulted in tripled profits!

Oh wait – did I say “triple?” How about 10x my profits?

This is even more impressive if the company is barely profitable. If our profit margin is only 1% before improving the team, then improving the team can increase my profits by a factor of 10.

Unwinding the example

If I want to pitch retrospectives. I’m going to use some of these ideas. If we do retrospectives or debriefs:

  • The team will learn 10x faster
  • Therefore, we will get better quality products to market faster
  • The result will be as much as 10x the profits

I illustrated this in terms of retrospectives. But the same kind of thinking can apply to many other kinds of improvement.

How to turn 20% into 1000%

  1. Find the baseline, call it X. In the example the baseline is the rate at which the team is improving without doing retrospectives. They’ll naturally improve some, but not as much. Let’s say it’s 2% (per year).
  2. Find the improvement to the baseline, call it Y. For retrospectives, it’s 20% per year.
  3. What’s the ratio between the improvement and the baseline (X/Y)? For retrospectives it’s 10. This means that in the retrospective case, the team is getting better 10x faster.
  4. Optional next step: What does that 10x improvement mean in terms of business results? There are a few big ways to improve the business – get to market faster, win more of the deals you get into, get into more deals, open a new segment, increase the total addressable market (TAM) of the segment you’re in. Improving the effectiveness of the development team can impact four of those five.
  5. Figure out how impacting one of more of those factors affects revenues and profits. Especially for profits, and especially if you are starting at a point of low profits, you can often get amazing multipliers for just improving your processes a little bit.

 


02
Jun 17

How To Talk To Your Executives About Agile

People have asked me “How can I get my execs to support an agile transformation? They don’t like that they can’t predict anything.”

Reframe the Agile conversation around value

Graffiti on a wall spelling out the word "Value"

Orient the conversation around value, not around methodologies. (Picture credit below)

This is never going to be an easy conversation, but I recommend reframing it from the outset. Don’t talk about scrum or methodologies or the Agile Manifesto. Instead, talk about delivering value to the market and how your products and your company can be more successful.

Among the things keeping executives up at night are the following three questions:

  1. How can I get higher quality products to market faster?
  2. How can I motivate my teams and help them improve?
  3. How can I stop failing in my predictions of what we’re going to deliver?

Help your executives sleep better

If you take these questions to heart, you’ll find there are solutions. And as you implement these solutions, you end up doing agile or something that looks very much like it. (Another way to say this is that you implement agile to get good answers to those questions.)

  • To get higher quality products to market faster, you need to focus on and prioritize adding the highest value capabilities to the products. And you must stop adding low value capabilities. You get two benefits from this. First, because you aren’t working on lower value stuff, the time the team spends is intrinsically higher value. And second, your team is naturally going to be more motivated because they are working on higher value stuff. Focusing on value helps with the first question and part of the second question.
  • I’ve already talked about how to motivate your team more effectively. How do you help them get better? How do you accelerate your team’s learning cycle? You make the cycle of review and learning a lot faster. The “retrospective” is a key part of the scrum methodology for just this reason. The team does its learning as closely as possible to the action. It also helps if you can have the team accomplish things on that short cycle as well. You may need to do clever partitioning of those important things you are working on.
  • There’s only one way to stop failing in your predictions. You must stop trying to predict the future. We all know it doesn’t work. Even if you have a concrete plan, with “good” estimates, you will not hit it. (It’s never been done.) Instead of predicting what you will deliver when, use a value-based approach to talk about what’s coming. You can confidently say “Every release will have the most valuable capabilities we could deliver in the time frame.” You may not know exactly which capabilities those will be in advance. But you can be confident they are the most valuable things you could possibly deliver. So rather than focusing on hitting a schedule – which is an internal target that customers mostly don’t care about at all – you are focusing on delivering value to customers – which customers do care about, which is much more valuable.

Value and velocity – related but not the same

I’ve separated maximizing the value of the results the team delivers from continuously improving the team’s ability to deliver.

These two ideas are often munged together in agile discussions. Indeed, by focusing your team on delivering value fast, the team naturally gets more motivated and faster.
But the second half, of accelerating the learning of the team, is not necessarily about “agile.” The practice of retrospectives or debriefs gives you the other dimension of team improvement – continuous learning. To accelerate continuous learning, you need to make the pace of the retrospectives faster. It’s much better to do learning near the actual experience. And since agile methodologies have short sprints, doing a retrospective for each sprint is a natural way to accelerate learning.

From Value-focused to Agile

If you combine all these thoughts, there are four aspects that combine to make more productive teams:

  • Making sure you’re always working on the most important thing or things
  • Continuous learning
  • Not predicting the future
  • Fast paced iterations

And, if you have those four things, you get four side effects, all very valuable:

  • Agile as a side effect
  • More effective teams as a side effect
  • More revenue faster as a side effect
  • Higher value products to market faster as a side effect

And there’s one other side effect. If you are working in order of importance, you can also push that practice back to the requirements and planning stages. The product managers only need to write requirements and do planning on the next most important capabilities. Requirements for less important capabilities can be delayed until they are needed. This means the development process can start sooner. And that accelerates your time to market even more.

How you can put this into practice today

Here are three things you can do today to start putting these ideas into practice.

  1. Start thinking about value value value, all the time. Only work on the most valuable things you can. Or, to put that another way, don’t work on things that aren’t valuable, even if they are cool or fun.
  2. Make sure your development team understands the value of what they’re working on. You can use the template I mention in this article to help: This New Template Helps You Write Better Product Requirements.
  3. When you talk to your execs about agile, don’t talk about agile, but about delivering value to market faster. Which results in higher revenue and more profits. Execs are typically much more interested in higher revenues and profits than they are in development and project management methodologies.

Image credit

  • “Value” by J.Lightning. Copyright (c) 2011 J. Lightning, Attribution-ShareAlike 2.0 Generic (CC BY-SA 2.0) 

08
May 15

5 Tips For When Your Release Is Running Late

The other day I got a question on a PM chat system:

“Wanted to tap into the experts here, although might sound like a stupid question. What are some of the PM strategies to apply when you know your product release is running behind schedule?”

As software product creators, most of what we do is surrounded by uncertainty. How do we keep our releases running on time despite all that uncertainty? How do you get to a point where you’re never behind schedule even though you are inventing the future?

Vintage Train

Vintage Train (photo by Tim Abbott, CC 2.0 license)

After ensuring the questioner that this never happens to me (LOL), I came up with a short list of ideas that I hope will be helpful. There are, realistically, a few things you can do.

  1. Make sure you’re always working on the most important things (aka agile). That means that at least the stuff you are getting done is more important than the stuff you aren’t getting done. ([tweetthis hidden_hashtags=”#prodmgmt” remove_twitter_handles=”true”]Agile means “the features you aren’t delivering are less important than the features you are delivering”[/tweetthis])
  2. Recognize that software dev/product dev is inherently highly uncertain – it’s invention, and at best your estimates are predicting an uncertain future. As Yogi Berra famously said, “Prediction is hard, especially about the future.”
  3. Use a “release train” method – the release always leaves the station, and anything that’s done, or “done done”, goes on the train. Things that aren’t done wait for the next train. This means that releases always go out, and features go out as they are finished. That’s hard if you have big monolithic features that take a huge amount of time and effort to complete. Try to avoid having those, or at least try to avoid delivering those as monolithic features.
  4. Sometimes working 24 hours a day for a short period can work to recover a schedule. But it has to be a short period, with a very focused – and important – goal. You can’t do it often, and you definitely need to show a lot of appreciation for the efforts and sacrifices that people are making. And they have to see that their efforts also resulted in a good outcome. Otherwise it definitely won’t work a second time.
  5. Obviously, you have to be really good at cutting scope. An especially important PM skill is to be able to work with the dev team to surface and eliminate assumptions that cause development costs to go up. ([tweetthis]Key #prodmgmt skill: be able to surface and kill assumptions that cause dev costs to go up[/tweetthis]) For example, it’s often much cheaper to stub off unlikely corner cases than to do costly additional coding to support them.

Those were the thoughts I had – what do you do when your release is running late?


24
May 13

Accelerating Change In Your Face

Exponential Change: A Handy Mnemonic

We all know change is accelerating, but, as Peter Diamandis points out, things can be deceptively slow before the exponentials kick in. In this video, in less than three minutes Diamandis shares what he calls the “Six D’s Of Exponentials” – things to look out for as the world changes. Nowadays this change usually starts as Digitization, his first D, and it starts out Deceptively slowly, his second D. I’ll let him share the rest of the D’s.

The most significant of the D’s, from the standpoint of product managers, is the fifth one – Demonetization. These transformations continually make goods and services cheaper, particularly if they can be delivered or implemented digitally. This suggests, at a minimum, that our markets have shorter and shorter lifespans.

Agile Everywhere

On the topic of change, I ran across this second video from Bruce Feiler yesterday, from a TEDx conference last year. It describes how the speaker took the concepts of agile development and applied them to managing his family – chores, bickering, choosing vacation spots – to great success. This is a different kind of change, a change of thinking, that’s the type of thing we’re going to need more of in our future. Many of our beliefs and common knowledge about the world turns out to be outmoded and old-fashioned, ready to be replaced by new ways of thinking. Whether it comes to family dynamics, or teaching, or government, or the economy itself, old ideas are rapidly running out of steam, and failing to produce as much value – both societal and economic – as we need.

Have you run across new ideas or examples of accelerating change in unusual places?


22
May 13

The Challenge of Roadmaps

Rich Mironov reposted his great article, Magical Thinking and the Zero-Sum Roadmap, about the physics of roadmaps yesterday at the same time I posted my closely-related tidbit about delivering late being better than delivering on time but with low quality. Not a surprising coincidence, since getting product out there is something that occupies our minds tremendously. Rich summarizes his key point as Mironov’s Roadmap Theorem #1: “You can’t put something new into the current development plan without taking out something of equal or larger size.” And that’s a law of physics. Just because the software you write doesn’t need to obey the laws of physics doesn’t mean that the laws of physics don’t apply to its creation.

Predicting the Future – Another Name For a Roadmap

We all love roadmaps, at least our bosses do. They want to know what’s going to happen in the future, and usually they also want to know how much of you’re going to sell, and how each individual feature is going to pay for itself. If you think back to my “Radically Different Manifesto For Agile” post of two weeks ago, you’ll recall my first thesis was “It’s fundamentally better to not try to predict the future. Do your best to predict only as little of the future as you can get away with.” The other points in the post align with that, all based on the ultimate point – predicting the future in detail is impossible. This is a statement we all agree with, right?

Of course, you can predict some big things, what Daniel Burrus in Flash Foresight calls “hard trends.” Computing power will basically double every 18 months – this is one of the most consistent trends in our modern experience, and may even be a law of physics. But, you can’t predict the specifics of those trends – what our computers will look like in five years, for example, or which technology will win the next computing paradigm in 10-20 years.

The Creative Act

So, we know that the details of the future are impossible to predict. But that’s compounded, at least in the software world, by the fact that software doesn’t obey the laws of physics. Another way to say this, as Kurt Leafstrand did in his Medium article Don’t Build, Compose, is that in a software startup, “You’re writing a novel, not constructing a bridge.” Or, not to put too fine a point on it, creating software is not engineering in the same way building a bridge is.

Software is a creative endeavor, more like writing a novel. I talked about this last week in Product Management and Fear. There is no right way to get to the goal, for every new feature in your product you’re starting with a blank page, and you’re likely to go down a lot of rat holes before getting to a form that’s delightful and delivers value. In the article Leafstrand says engineers often need to “tweak the storyline a bit.” I’d go farther – “tweaking” doesn’t quite capture it – I’ve heard authors describe needing five completely different drafts of a novel – different tense, different voice, different characters – before they find an approach that works. As product people, our fantasy is that we’re only a few tweaks away from success, but sometimes we need to shift gears completely in order to make progress. (Hell, every paragraph of this blog post has gone through at least three edits!)

We are therefore put into a difficult place – we want the ability to predict the future (that is, a roadmap), we have constant pressure to add to the roadmap without changing the dates, and we’re writing a novel, in practical terms.

Roadmaps Become Perceived As Reality

And then, unfortunately, the roadmap usually transitions, in peoples’ heads, into reality. Our best guess at predicting the future, which was at best always optimistic, becomes the expectation outside of the product team. In the meantime, inside the product team reality is asserting itself and we are doing our best to deliver the most value we can using agile to prioritize the most important features first, and striving to avoid what I wrote about yesterday (delivering something “on time” but crappy) and instead deliver something incredibly useful, engaging, and that people will buy. On whatever schedule that takes (within reason).

There, in a nutshell, is why product management is not just a fun job, but a tough one. If you can dance that dance, and not get fired, and still get software out, and love doing it, you can be a product manager.

 


14
May 13

A Radically Different Manifesto For Agile and Lean

I do not like the agile manifesto. It does not resonate with me as a product manager – someone responsible for guiding successful products to market. It’s very focused on the needs and desires of developers, and much less so on my needs and desires, or more importantly, on those of my customers and prospects. But, I love agile, and I believe agile – and its follow-ons, like lean and kanban – are critical to enable people like me to create and deliver new products that create value in the world.

My Six (Not 99) Theses

What is it about agile that turns me on, while the agile manifesto itself leaves me cold? I’ve made a stab below (and made other points elsewhere) at a high-level explanation for why I like agile and why I think it works. It’s based on some tenets or axioms that lead to the conclusion that an approach like agile is generally superior for delivering value than more traditional approaches like waterfall. I guess these are my version of a manifesto, one that leads to agile and lean when they are applied to product development:

  1. It’s fundamentally better to not try to predict the future. Do your best to predict only as little of the future as you can get away with.
  2. It’s fundamentally better to be responsive to changes, especially as change happens so fast.
  3. It’s much easier to predict how long it will take me to do one thing than it is to predict how long it will take to predict multiple things.
  4. Don’t try to predict where you’ll be a long time in the future. Instead, keep your prediction interval as short as possible – you’re much more likely to be correct. (E.g., if I travel at 50 mph on this road for 15 minutes I can predict with great certainty where I’ll be, but if I have to predict where I’ll be in two weeks’ time, I could literally be anywhere!)
  5. Predicting what the market will want far in the future is extremely difficult, so instead do your best to only have to predict what the market will want in the near future.
  6. “Work in progress” is fundamentally a type of waste – this is a tenet from lean manufacturing and the Toyota Product System, but it also applies to software. Software that’s been developed but is not in use by customers – the definition of “work in progress” for software – is wasteful. Even if it eventually provides value for customers, it’s not providing value right now, leading to an overall loss of total value, which is undesirable. Note: This also applies to requirements – a fully fleshed out requirement that no one is working on is waste, so my recommendation is “don’t do that.”

If you combine those tenets “agile” naturally pops out: Don’t focus on optimizing a large set of work, instead focus on completing the most important piece of that work, as quickly as you can, and deliver it. Since you’re only delivering a small chunk, you don’t have to predict very far into the future. And you’ve chosen the most valuable thing to work on, so you know your market will want it. Because you are working in small chunks, if the market changes its mind, you can quickly change your plans in response. And by always having only a small amount of work in progress, you reduce waste and create more value.

Agile, Upon Analysis, Turns Into Lean and Kanban

In this analysis, though, it’s not really agile that pops up, it’s lean, or more accurately, “Kanban” (at least as practiced in software development). No matter how long your sprints are, some of your features will take longer than the sprint length to deliver to the 80% level. This is a big problem for agile methodologies, because a feature that’s only at the 60% level (which perhaps you can get done in one sprint) doesn’t provide significant business value, and usually neither you nor your customer gains by delivering it at that point. (There’s clearly another blog post in this topic of 60% value versus 80% value.) And therefore Kanban’s approach, which I will simplify as “take your three most important features and work on each one feature until it’s deliverable, then deliver it, and then start on another feature,” does a better job of delivering value to the market and reducing work in progress.

I’ve used the term “lean” above, and I’m really talking about the concepts that come from lean manufacturing. But these ideas are also intimately tied to the “lean startup” mindset as well. One of the key insights of the lean startup is that instead of guessing or predicting the future (all the things I’ve said you don’t want to do), you create hypotheses and test them, getting real data about how customers respond to your product and its features. Agile and lean and kanban again perfectly align with that approach:

  • Get “finished” work out to the customer as soon as possible to find out if they like it – after all, there was a hypothesis that drove the feature or whatever it is, and you want to test whether the hypothesis was correct or not. If so, yay!, and your customers are going to be more successful faster. If NOT, then yay! You have learned something that you can immediately address without letting the issue wither on the vine.
  • Instrument the product so that you can understand how it’s used over its life. This way you can find out what users do with the product, how they’re using it, where they’re running into problems (using the same techniques as webmasters use to assess the usage and obstacles of their websites).
  • Getting features out earlier means that you can get paid for those features faster, whether this is due to existing customers expanding their installations, or renewing their maintenance, or due to new customers coming on board because they heard from their friends (or via an evaluation) that the product does more of what they need better. In other words, more features earlier means a better top line. And the top line is the one that grows the economy – both yours and ours.

Do We Need A Product Managers’ Agile Manifesto?

I don’t know why I feel the need to reinvent things, like the agile manifesto, but there you go. I’d love to start a conversation about this, and if other product managers resonate with my ideas here, perhaps we can refine them and put out our own manifesto on how to deliver more value to market, faster.


07
May 13

Agile vs. The “Big Dog” Feature

(First published back in 2010, this article is still apropos and I thought it was time to revive it.)

Managing big features using agile

This post originated as a comment on the Cranky Product Manager’s blog, responding to her post on agile methodologies. She said

Yes, Agile can speed up the development and improve the quality of small features.  But it’s too often at the expense of the Big Important Work — the heavy lifting, multi-month market analysis and architectural work that lead to REAL customer value and REAL competitive differentiation.

I magnanimously offered my perspective on agile, boiling it down to the key points of:

  • Do the most important things first
  • Be prepared to reprioritize on a regular basis as the environment changes

Or, “spend your resources on the 20% of capabilities that will get you the best return.”

So far, so good. Can’t argue with that as an approach, not just for developing software, but for living life itself. And for the self-help industry, which generates tens of thousands of pages on the Pareto Principle every year. And I’m sure CPM, as we call her, was super-happy that I clarified that.

How waterfall falls down

In contrast, the old way (aka “waterfall”) is more like:

  1. Figure out what you want to accomplish
  2. Determine the most efficient way to accomplish it

It’s easy to see waterfall’s problems when characterized this way:

  • You have to know up-front what your end game is – which makes it hard to respond to market changes
  • The most efficient way of building the full product is not necessarily the one that front-loads the value, so often low-value items are completed and high-value items end up deferred
  • You do a lot of work up-front to document things that the developers never get to

Notice that’s not how agile talks about itself. The agile manifesto talks about working code vs. documents, and interactions over tools (it does cover “responding to change”). In fact, agile, as far the methodologies and manifesto go, is solely focused on programming. (This is changing some – I just listened to Kent Beck’s talk at the Ruby On Rails conference last year, and he’s come up with a very different characterization of the goals of agile: it provides accountability, responsibility, and traceability.)

How agile lets you tame the big dog

Now, given my characterization of agile’s – indeed, life’s – key goals, you can then look at agile  methodologies simply as one way to accomplish those goals. But what if, as CPM fears, the most important capability (call it The Big Dog) takes longer to deliver than a sprint or two, and requires visits to lots of customers to understand their problems, and lots of reviews with customers to see if we’re solving their problem?

Clearly, you still have to do the Big Dog. CPM should be able to tell you why. And if the methodology doesn’t give you a way to do it, then the methodology won’t work for that product.

But chances are the 80/20 rule applies to the Big Dog, just as it applies to everything else. And this large monolithic capability can be broken down sensibly into multiple passes through the “smallest thing that could possibly work” approach. Does this require the PM to keep ahead of the development organization? Yes. Is that any different from the old days? Yes and no. The PM needs to figure out the most important part of the Big Dog (the 20%), and make sure it’s understood, there are good user stories, it’s designed, architected, etc., extremely well. After all, that’s where most of the value is going to come from.

But the PM doesn’t need to document the rest of the 80% until later – if at all. In fact, it’s likely that finishing the 20% of the Big Dog prioritized to the top of the project leaves something else – the Medium Kahuna – as the next important item to accomplish. There may be some additional Big Dog-related capabilities that are “nice to have” – and they’ll be prioritized into the rest of the project, if there’s time after getting the Medium Kahuna delivering its value.

“Now wait,” you (or the CPM) say, “I can’t live with only 20% of the Big Dog – I need 100% of it – or at least 80%” And I say this is where the beauty of the agile mindset comes into play. If you’ve completed 20% of the Big Dog, and have the rest of the Big Dog as well as the Medium Kahuna in your backlog, at this point you can decide which is more important, and decide which one to do. You’re already delivering 80% of the value of the Big Dog – now you can decide if you really need to take that up to 90%, and leave the Medium Kahuna on the table, or vice versa. You have control.

Agile can’t solve every problem, but can tame a lot of big dogs

Agile is not a silver bullet, and it’s hard to get right, but if it helps you focus on putting first things first and executing on the 80/20 rule, it’s done its job.

Your thoughts?


13
Aug 12

The Best Way To Understand Agile

I was chatting with Jason Tanner of Enthiosys the other day, and he asked me how I defined “Agile Product Management.” What follows is more or less my answer, formatted a bit for the purposes of the blog.

First, what is agile?

All my discussions of “agile” anything start from how I describe agile at the 30,000 foot level, with the following rules:

Sprinting! (A sprint car at Eastbay Raceway in Florida, by jokerswild1963, CC 2.0 licensed)

  1. Figure out what you want to do
  2. Figure out which of those things is the most important (“predicting the future” step)
  3. Do the most important thing until it’s done (“done-done“)
  4. Go back to #1

Each time through that set of steps is an iteration or sprint, and you’re likely to have a lot of sprints before you get to a release.

I contrast this explicitly with the comparable rules for “waterfall”:

  1. Figure out what you want to do
  2. Figure out how to those things in #1 most efficiently (predicting the future step)
  3. Do those things in the most efficient order

It’s a subtle difference when shown this way, but the difference is critical, and for a number of reasons:

  • Each time through the agile process (each iteration) you have the option to define a new set of “things to do” – this means you can respond to the market, or realize that your original idea was wrong, or realize that you can’t actually accomplish your original idea, or refine the idea or design to be better, whatever it might be.
  • All management disciplines suffer from the fundamental problem that predicting the future is hard or impossible. No matter how much you know, your predictions are likely to be wrong, and to get wronger as your prediction horizon extends. The benefit of agile is that your horizon for predicting the future is very short – what’s the most important thing to do right now? – while it’s very long in the waterfall case – “what’s the optimal way to do all these things?” As a result, the damage to the project from incorrectly predicting the future is much more contained with agile – to a single sprint or at most a few sprints. In lean, it might be contained to an even smaller increment.
    • (Sidebar: Why is predicting the future so hard? Three reasons – one is that things change, so what seems important today might not be important tomorrow; second, you might need working code to understand what you really want; finally, development estimates are never over estimates – everything always takes more time than estimated, never less time.)
  • Agile explicitly supports the Pareto Principle (or the 80/20 Rule), while waterfall doesn’t have a good way to do that. In other words, in any set of things I want to do, 20% of them will give me 80% of the benefit, and in agile I make sure to do that 20% first.

Applying these ideas to product management

Given this, how do I define agile product management? The steps for agile product management are no different than they are for other agile activities (like agile project management, what we usually mean when we say “agile”). Figure out all the things you want to do, prioritize the list, and do the most important thing on the list, then repeat.

What does that mean in practice? It means don’t spend time on unimportant things. Always know what’s most important (how I determine that is covered in another post), and focus on getting that to “done done” before doing something less important. And then when you’re ready to start again, redo the list, and reprioritize. As a product manager, I make a list of the features needed by the customer or the market, prioritize it, and write detailed requirements for the handful of the most important ones. Those I then socialize with the engineering team, both to get their rough estimates, as well as qualitative feedback on the feasibility of the features, open a conversation on what the feature really is, get ideas and innovations from engineering that might make the feature more valuable, and so on. That’s one iteration – then I do it all again for the next iteration.

Contrast this with a non-agile approach to product management. I’d start with the same list of features for the system, then write all the requirements, in enough detail for engineering to estimate them all. Then, after a lot of discussions, covering all the requirements (let’s hope we don’t miss an important one!) I got the (wrong) estimates from engineering, I’d then lay out the tasks in an optimal way to get all those requirements delivered, balancing a desire to get full functionality with a need to meet certain market milestones. Because I’m predicting the future, the resulting schedule is guaranteed to be wrong, and it will always be wrong in the undesirable direction.

But there’s some stuff missing!

At first glance my definition of agile may seem simplistic, and even missing something – where is all the stuff that people usually think of when they hear “agile”, like Scrum, sprints, retrospectives, velocity, and all that?

My point is that agile is not about specific tools or techniques (although agile methodologies may define or specific tools or techniques) – it’s a mindset about getting the most important stuff done-done as quickly as possible.

But let’s expand it a bit more and talk about where all that “agile stuff” is – or rather, where it arises from given my definition. For example, there’s a claim that agile teams keep getting faster, and they work more collaboratively and generally are superior to teams that aren’t using agile. But what’s really happening is that if you run a project based on my definition of agile – whose primary output is to get the most important things done first – you get lots of additional desirable side effects. You not only have a much better approach to the project management side, but you get to take advantage from a management perspective.

If people are always working on important stuff, then they are going to be more motivated to do a good job – this will improve quality over time. And if we’re getting insight – and corrective action – into how things are going on a very short timeframe, like a two week sprint, then we can apply changes directly when they are needed, and over time we can apply a LOT of changes. Simply doing a retrospective every sprint, rather than every project, gives you a lot more leverage, for three reasons:

  1. The problems are still fresh so it’s easier to see solutions
  2. The solutions you apply early on benefit the entire rest of the project
  3. You end up getting to apply a lot more solutions.

If you only do a retrospective at the end of the project, as in waterfall, then you’re going to forget some of the problems you had, you’re not going to be able to fix all the problems you do remember because the change will be too big to do at one shot, and only the next project will benefit, not the one that just finished. All in all, a nearly complete waste.

In fact, you might want to think of my rule #3 as having a sub-step – “3.5. Take advantage of your new experience to improve your process.” That will happen every iteration, and you’ll get better a lot faster.

That’s the primary way you get better as an agile team, although there are a few other well-known practices you can apply that will immediately start to give you benefits, like team programming and other collaboration approaches, making sure that everyone on the team takes responsibility for getting to done-done (meaning that developers sometimes do a lot of testing, and testers contribute a lot to development), and always having a deliverable product.

What do you think?

Does this definition of agile resonate for you? Do you use another formulation that captures the key driving benefit of the agile approach? Do you have additional questions about agile and how all the benefits of agile arise from this simple set of rules? Let me know in the comments.

I’ll post again soon about agile, specifically answering why these rules result in getting better quality products to market faster. That’s another promise from the agile camp, and it’s interesting to think through how it happens. And we’ll touch on how to talk to management about agile. Management has historically liked the waterfall approach, because people it appears to be predictable – although the predictions are always wrong (way wrong). Agile seems suspect to management, on the other hand, because you can only say “we’ll get the most important stuff done first,” but you usually can’t commit to when that will happen.


07
Jun 12

How to Prioritize: Top 6 Techniques

Too much to do

As a product manager, one of the fundamental issues you will have in your life is that you will have a lot of things to do, and you won’t be able to do them all. Whether it’s the list of features and capabilities you want to implement in your product, or the customers you want to visit and get insights from, or the anthropological studies you should be doing with prospects in your market or the market you want to get into, you will not be able to do everything you want. This means you have to prioritize your activities, and what you ask from your developers (i.e., in terms of features), but you also have to be able to defend and justify your priorities to your supervisors, to the business, and to the people who are executing the work you have specified.

Priority!

Prioritization is a critical capability for product managers

In this post I outline some of the basic concepts of prioritization, which we will explore in more detail in future posts. I’m not going to cover everything there is to know about prioritization, but give a number of techniques that (typically in combination) you can use to help you make better decisions about what to do. Better, at any rate, than simply flipping a coin. Of course, nothing is guaranteed – as many a product manager has discovered before me, you can make the best decisions in the world and your product may still fail for reasons beyond your control. But if you want to have the best shot, here are some of the things you should think about.

Techniques of prioritization

I’m going to write this as though the priorities were new features for your product, but the same ideas work for other things you might need to prioritize:

  1. Trust your instinct – more on this in a future post, but remember that one of the reasons you are a product manager is that you have specific expertise about the product, or the space, or about decision-making per se. So your gut feelings are likely to be decent. On the other hand, if you’re like me, you want something more concrete to backup your decisions.
  2. Analytics – either qualitative or quantitative. The types of analytics you can use to support your decisions varies widely. For example, if you have talked to several customers about a new feature, and they’ve all said it would be highly valuable to them, and your gut says most customers would get value from it, that might be enough “analytics” to move forward. Analytics can get a lot more sophisticated, of course – people use spreadsheets comparing the revenue outcomes for different combinations of features, and tools that graphically illustrate how well a set of requirements satisfies a set of prioritization criteria based on a market model, to tools that use “option pricing” and other advanced financial techniques to give you a numeric priority value. Analytics are the best tool in your toolbox for defending and justifying your decisions.
  3. Stack ranking, and ignoring things at the bottom of the stack. Part of being a good prioritizer is not getting weighed down by the stuff you’re not going to be able to do, no matter how desirable it is. One way to help you achieve this clarity of mind is to stack rank your new features, with the most important ones – determined, perhaps using your gut instincts backed up with some analytics – and then ignore everything in that list after the first ten items. This is a fundamental technique from agile software development – once you have decided what is the most important feature to deliver, concentrate on delivering that feature and ignore anything else that’s lower in priority. Once the most important feature is delivered (or complete and ready for delivery), then you can revisit the stack-ranked list, review the ranking, make any changes necessary, and then focus again just on the top items.
  4. Doing tests with a “minimum viable product” or MVP – sometimes you have an idea of whether a feature or a tactic will be valuable, but you need validation from the market that your instinct – which we can call a hypothesis in this case – is correct. As in real science, you test a hypothesis with an experiment, which in the world of lean software development has come to be called an MVP – a minimum viable product. The phrase “minimum viable” means “the minimum amount of development needed to test the hypothesis.” Sometimes an MVP is as simple as a webpage, while sometimes it can be a complete development project in itself – it completely depends on the hypothesis you’re testing. The point is that you are not doing any more work than you have to in order to find out if your hypothesis is correct or not.
  5. What’s the worst thing that could possibly happen? The process of prioritization always has winners and losers, and one way to test whether your prioritization is correct is to do a thought experiment. For each of the candidate features, ask yourself, what is the worst thing that can possibly happen if we don’t deliver the feature? You can use the answers to this question for each feature to minimize the worst possible outcome. Of course, it’s very possible that not delivering a new feature won’t have a bad outcome, but delivering it would have an very positive outcome, so you can’t use this as your sole decision-making criterion.
  6. Make sure that your boss’s pet feature is handled. This may sound a bit cynical, but remember that you’re not just optimizing your development team’s efforts to deliver value, but you’re also optimizing your own career – your success depends on you delivering good products and on staying employed and keeping your boss happy. If your boss has a feature that he or she really wants to see in the product, then that feature has extra weight in your prioritization – you might still cut it, but you need to have an especially strong story for why that had to happen.

What prioritization techniques do you use?

That’s a few quick ideas on how to do effective prioritization of features into a release, or in general how to prioritize anything in your career (or life). Let me know in the comments if you make use of these techniques or if you have other prioritization tools you like to use.