Aug 13

More Compare and Contrast of Cynefin and The Lean Startup

I got some heat over the weekend from Dave Snowden (@snowded). I did a bit of a mangling of Cynefin in my last post. I want to clarify my comparison of Cynefin’s complex domain to the Lean Startup concepts. I understand that Cynefin is a general framework about understanding business problems and processes, while Lean Startup is about creating software. So why am I saying they are related? 

I’ve said before that complexity is the underlying problem of product management. Cynefin has a useful set of thinking about what to do in a complex domain. The Lean Startup, which is specifically about product planning, has a similar set of points. These points reinforce each other. And they validate my fundamental claim that we need to think about product planning as a different kind of beast than other business processes, especially when it comes to tools.

Let me give an example. 

Financial accounting is a “simple” domain, from a Cynefin standpoint. There are best practices, there is a right answer at the end of the day. For nearly any question, there’s a specific answer. 

If I’m thinking of making a software product for the financial accounting, there are a number of different components I could focus on, such as the General Ledger, Accounts Receivable, Accounts Payable, reporting. 

For each of these components I could either implement that component in my software or not. I could implement it as a version of the traditional approach – i.e., a ledger or a spreadsheet – or in any of dozens of different non-traditional user interfaces. I could put charting in my reporting or not. I could create an add-on to another accounting system. I may have a new feature that no other accounting system has. Or I could integrate with the CRM system. Thre is no a priori “good practice” I can use to determine the right decision in these cases.

Even the decision about whether to go into accounting software is complex. There are many accounting packages already, but not every vertical has their own package, and not everyone is happy with what they do have. Perhaps there’s an opportunity in mobile. And with some of the new ideas like “thick value” maybe we even need to move accounting from the “simple” domain to the “complex” domain itself. 

The point is that even for this simple discipline, creating software is complex. Each of the decisions I make has an impact on the decisions I made before and the decisions I make in the future. There is no right answer, and there is no best practice, and there is no good practice.

Given all this uncertainty, how do I decide what to do? Well, I make small experiments. In Cynefin these are called “safe-to-fail” experiments. In Lean Startup they are called “minimum viable product” or MVP. (Many people misunderstand the concept of the MVP, although Reis is very clear in his book what it means – the smallest amount of work necessary to test a hypothesis about the business. Compare this to Cynefin’s safe-to-fail experiments – “I can afford them to fail and critically, I plan them so that through that failure I learn more about the terrain through which I wish to travel.”)

The point is exactly the same. I have a question and a hypothesis about the answer. I need to to test it without committing too much effort. And I’m prepared to respond differently depending on the answer I get. 

The testing reduces uncertainty. The next phase in the Lean Startup is “Learn” – which is much like the “Sense” phase of Cynefin. “Let’s make sense of this result we just got.” How does it change or improve (or reduce) our understanding? Is our product concept still good? Do we need to change our focus? In the Lean Startup the change of focus is called a “pivot.” In Cynefin the response is called a “response” – and can be a pivot-like move, or a continue-moving-forward-type of move.

It doesn’t “matter” if Lean Startup and Cynefin are related or not. What’s interesting is that they seem to be saying something about complexity and how to handle it. And what they’re saying applies to product planning and product management, which is what I’m interested in. And it suggests reasons that product planning software has been so deficient in the past – it doesn’t understand that it’s trying to automate a complex domain. 

May 13

Create A Compelling Product Vision By Writing The (Amazon) Review First

One aphorism about creating great products is “write the datasheet first.” This is kind of a lean startup concept – write the datasheet and see if anyone likes it well enough to call you up and try to buy the product. It’s a kind of minimum viable product.

But I also like to take the opposite approach, and imagine “what if?” This actually works whether you are planning to build a product, or looking to buy one. “What if my product were out there and it was really successful – what would people be saying about it, why would they have bought it, and what kind of value would they be getting?” Or, “If I found the ultimate solution to my problem in the market, how would I be thinking about it, what would it be doing for me, and what might I tell other people about it?”

The obvious way to capture these ideas is in the form of Amazon reviews (five star, of course).

So, since I’ve been thinking about product management tools lately, from *both* perspectives – builder and, more recently, buyer – I thought I’d share some of these Amazon reviews. I emphasize, in case it wasn’t clear, these are made up – they are me imagining “what if?”. So here are some of those great five-star Amazon reviews for the product of my product manager dreams – ProductManagerPro.

  • ProductManagerPro Gives Me Analytical Backup For My Decisions

    By A Solo Product Manager

    “Using ProductManagerPro, I was able to start making much better product decisions, and then to make sure that my decisions were being properly carried out. Before I had ProductManagerPro, it’s true that I made those product decisions to the best of my ability, but I was never able to justify my decisions on anything beyond my strong (albeit well-educated) gut feeling. Having ProductManagerPro to back me up on these decisions has given me a lot more credibility within the organization, and has given me a lot more confidence that I’m doing the right thing. Add to that that I can now track how those decisions are progressing through my product development process, and I’m a very happy camper!”

  • ProductManagerPro Enables My Team To Do A Better Job and Keeps Everyone Aligned With The Product Vision

    by A Manager Of Dozens

    “I have a staff of tens of product managers and almost 100 developers. When my organization decided to go with ProductManagerPro I had my doubts – another management tool that, if we spent a lot of time on it, all overhead, my managers might get some useful information, but it wouldn’t help me at all. Well, those doubts were cleared up in the first few weeks when I found I was finally able to see what really was going on in my organization. ProductManagerPro’s information is at the sweet spot between high level strategy and low-level user story development, and allows me to see how the work my team is actually doing – whether it’s development or product planning – relates to the high level goals of the department and even the company as a whole, and not only whether we’re on track against those goals, but whether we’re aligned with them over time.”

  • The Developers On Our Team Love It!

    by A Die-Hard Agilist

    “As a developer, I thought ProductManagerPro was really not for me. I’m all for my product managers having a better tool than Word or Excel, and in fact I knew that automating some of what they were doing could help me out. But ProductManagerPro has surpassed my expectations. It turns out that it hasn’t added overhead to my process (thanks to the integration with our IDEs, I can get my tasks provisioned right within my development environment), but it’s given me a lot more information about what I’m working on and why. Sometimes people think us developers just want to be told what to do and then be left alone, but I find it very motivating to be able to see why I’m working on a particular little item, and in fact I think that knowledge helps me do a better job, because I understand a lot better how this function will be used, what other capabilities it integrates with, and how it relates to the overall goals of the company and the users using our product. In fact, because of ProductManagerPro’s great collaboration abilities, I’ve also been able to make suggestions to our product managers for enhancements or improvements to functions I’m working on, which they have agreed to, and which I know have been popular with some customers! And this could not have happened nearly as easily without  in the picture.”

  • It Helps Me Be A Better Product Manager, Right Out Of The Gate

    by A Newbie

    “I am a new product manager, having transitioned from an engineering role, and I found at ProductManagerPro really helped me make that transition in my organization. They had configured the system in a really good way so that I knew exactly what information I need to provide, in what format, so that me and my colleagues could make good decisions, and so that my old colleagues – the developers – could get the most value from the system. This ability to configure the system to match our business processes made a really big difference to how quickly I was able to ramp up, and also it kind of gave me – and I think the rest of the team – some ‘secret sauce’ for doing a better job.”

  • Enables Us To Automate The Only Business Process That Creates Money

    by A Numbers Guy and Executive

    “My company realized a few years ago that now that we’d implemented ERP and CRM, the only real competitive leverage we had left to automate was our product planning and development process itself. Of course, this is obviously the hardest thing to automate, but it also gives the most leverage, because a successful new product can really change the landscape for a business. So I started researching solutions for improving our product management process – about 100 product managers working with about 250 products and product modules and 1,500 developers. A lot of the solutions were clearly just toys when confronted with the scale of our operation. But ProductManagerPro was architected to address the kinds of problems a company like mine faces in the product planning and product management process.

    We’re now one year into the implementation of ProductManagerPro and we’re seeing lots of improvements in various areas, although we’ve still got a long way to go. Just getting our requirements into a central system of record – in a scalable way as ProductManagerPro allows us to do – has been huge. It’s turned our product planning process into an enterprise asset, whereas before, when requirements were scattered across various “systems” – mostly Word documents and Excel spreadsheets – there was no way to consider them an asset. And the visibility that ProductManagerPro has given our executives, from product VPs to C-level execs, has resulted not only in our ability to catch problems while they are still imminent, rather than emergent, and has also given the top execs a lot more confident that the product teams are aligned with the corporate goals and objectives. That in itself has made the company a much more pleasant place to work!”

Do You Have Tricks For Creating A Product Vision?

What techniques do you use for helping create a compelling product vision? Have you tried writing a review of your (future) product from the perspective of your ideal customer?

Also, if you’re a product manager or a development manager, don’t you just wish someone really would give us this ProductManagerPro package?

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.

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.


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.