• Humility so that you can accept being wrong without being crushed
• Empathy so you can put aside your own feelings and beliefs to understand the feelings and beliefs – and needs – of others.

I talked to a customer today about a new feature they want, and I was tested in these areas. The mockups that I spent days working developing were not well received, although they precisely match the process as they described it to me. What they say they want sounds like unicorn tears, but that’s not *their* problem – it’s mine. I haven’t heard them right yet. I’m confident I will, but there may be several more uncomfortable demos before I’m not wrong anymore.

(Inspired by George A.’s “Number One Job Skill In 2020” post on LinkedIn – hint: the skill is empathy.)

It’s obviously great for reading the news. If you don’t want to waste your time, ask yourself, for each article, “will this still be interesting to me in two weeks? Is this news that will make a difference past today?” Most of it will simply be forgotten tomorrow, much less in two weeks. And if it’s still around in two weeks, you’ll be able to get the whole story at once – which also saves waste.

Will this still be important in two weeks?

Does this work for product management as well? Of course! Flavor-of-the-week management fad? Exciting new Javascript framework? A new innovation technique that the CEO wants to try? Ask yourself if it will be forgotten in two weeks, or if you should invest your attention immediately – your attention that’s already got more work than it can do. Often the best approach is to play along, but not get invested for two weeks. Continue to focus on the important actions you already had planned. If the new shiny thing is really important, in two weeks it will still be there, and there will be a lot more information available to take action against.

1. The Apple way – Invest a huge amount of money to create an amazing product that innovates in a number of different ways and redefines a market, as Apple did – at least $150 million to develop the first iPhone, (maybe more). Note: This doesn’t always work – Nokia did this with feature phones and the first smart phones, but failed with their second smart phone.
2. Provide a solution that’s technically superior and solves a problem people don’t know they have, and then grow fast enough that network effects start driving customers to you. Then figure out how to make money. This is the Google and Facebook way.
3. The normal way – grow a $4-5m product that solves an important market need to a $10m product, then to a $20m product, then to a $50m product, by doubling your revenue ever year (which is fast growth!). Then add to your product line and continue to grow to get to $100m, then grow those and acquire competitors or partners to grow to $250m, continuing to grow your other products. Keep growing 20% per quarter, and pretty soon you’re at a run rate of $1b.

While we all want to be “the next Google,” most companies that get to $1b in revenue do so not in a rocketship, but by consistent, long-term blocking and tackling. And not with a single product, but with multiple products, that grow quickly but not astoundingly, that start with $10m in revenue, then $20m, and so on, managing their growth well. To keep growing they add new products to their portfolio organically, and via acquisition.

A successful product meets three key requirements:

1. It significantly improves some important aspect of the customer’s process or life. For a top line improvement, aim for 20% or more (increase sales by 20%!). A bottom line improvement better be an order of magnitude (reduce errors by 90%!).
2. It works. Customers sometimes can live with imperfections, particularly early on when you’re delivering so much value they’re willing to take some limitations. But the product better not fail in stupid or obvious ways or you’ll never get a second sale.
3. It fits into the customer’s existing processes. There’s a process that precedes whatever your product does, and a process that follows it. Your product has to mesh with those, or it will be an orphan.

Make sure your product delivers on these requirements (and you can articulate how it does) to significantly increase its chances of success. (This is the TL;DR version of my Product Management Rules of Thumb series)

People remember experiences. They don’t remember attributes or benefits or features.

The quote is from A.G. Lafley, CEO of Procter and Gamble, in the January 28, 2005 Business Week.

It’s something I struggle with often as a product manager. Like most product managers, I’m technical, so I love all the new features and gewgaws. But as I look back at my previous releases and at customer response to them (and my own response – at my previous job I used my own product on a daily basis), I find it hard to remember which features were new and which were always there. My experience today with the product is what matters – it’s a great result when the improvement of experience aligns with the new features.

I’m happy to say that the new version of my product is delivering some experiences that my customers are getting value from. But I’ve certainly shipped features in the past that excited me as a technologist, and that were expensive and fancy and worked well, but that didn’t improve the customer experience.

In yesterday’s article I listed three powerful tips for starting to get through a creative block. Although focused toward product managers, the tips are really general purpose ways to increase your creative output.

1. Morning pages
2. Crappy first drafts
3. “Use Your Obvious”

You can summarize the three tips pretty easily, despite their variety – “Just Write!”

In this article I’ll cover more tips that are especially applicable to product management.

Use multiple modalities

More than most other creative domains, product management is a multidisciplinary activity. All of our work has a technical aspect, a creative aspect, such as the UI, a marketing aspect, the sales aspect. And this gives you powerful tools to unblock your creativity. If you’re blocked with writing a requirement, you can design a UI, and so on. I call this approach to your creative problems “multimodal.” The big benefit of this approach is that if you get stuck on one mode, you can often get started on another mode and continue to make progress. And because all the modes are interdependent, making progress in one area will often free your mind up to make progress in other areas.

Suppose you are working on a new feature, but you’re not quite sure how to articulate the user story for the developers. Instead, you might attack it from a different perspective – you could start by describing how the user would experience the feature – how it would help his or her day-to-day life. Or you could start by writing down some technical constraints on the feature – what technology would be used, or how it would interact with other existing features to make sure no value is lost. Or, in a very traditional approach, you could start by writing the datasheet for the new feature. And of course you could start by sketching out a user interface.

(And remember to apply all the rules from yesterday’s article, especially “crappy first drafts” – your first drafts are often not going to be usable, but they’ll give you insights to use for your second and final drafts. )

Conceptualization tools

So far, I’ve described techniques that concretely help you make the actual content of your requirement or marketing piece and all related components.

But, as my friend Scott Gilbert (with the awesome Twitter handle @AgileProducMgr) mentioned in a comment on LinkedIn, you can also use tools that help you conceptualize the problem. A novelist might use a story board, and a timeline, and a cast of characters, to conceptualize his or her novel. These all help develop the story, and prep for, but do not precisely achieve, getting words on paper.

We can use those techniques as well. In exact analogs to the novelist’s story board, timeline, and cast of characters, we can explore the timeline of the feature, how it fits into the process flow in the application, and list the users of this new feature (or as they’re often called, the personas).

As I determine if my design supports different aspects of politeness, I move the aspect to the Yes branch, with an annotation saying how it’s polite in that way.

Another tool that works very well for conceptualizing a new feature is a mind map. I use a free mind mapping tool called Freemind. Scott uses MindJet, a commercial product. We both got a lot of value from creating mind maps – they help us understand the frameworks of not only the problem that we’re trying to solve, but also how the solution might come together, and how the solution will address the -ilities like usability and scalability. In particular, I use a mind map template that I’ve created to help me characterize the user experience and interaction design aspects of a new feature as I’m designing it. My template basically outlines the key aspects of user experience as described by Alan Cooper in The Inmates Are Running the Asylum (including the 17 aspects of politeness), and I use the mindmap to make sure I have good answers to every aspect as I’m designing the feature.

Tomorrow – PM-specific Tools, Not Just Techniques

Today I focused on techniques that are well-suited to product management’s multiple modalities. The next post in the series will be about tools that are specifically designed for PMs and how they can help overcome creative blocks. Unfortunately, as you’ll see, some of those tools so far only exist in conceptual form – that is, in my mind.

A few days ago I said that fear is one of the big problems product managers face, in our creative role of finding new solutions to new problems. Much of the time we’re looking at a blank page that we need to fill with requirements or a datasheet, or a blank screen that we need to put a user interface on, or a blank set of slides that will eventually be used to sell our product. And a blank page is a recipe for fear – fear of failure, fear of not coming up with the right solution, fear of missing something obvious, or just fear that this time the magic isn’t going to happen.

A big part of the literature of creativity is focused on how to overcome fear. In other domains they call it by different names – writer’s block, or stage fright, or creative block. I find many of those techniques are valuable, and some I use every day (like morning pages). But there are also product management-specific techniques that can help. And there are some product management tools that, if they existed, would help overcome fear. Today I’ll start with some of the techniques I use that come from outside the world of product management.

General creativity techniques

1. My favorite of these is morning pages, from Julia Cameron’s The Artist’s Way (highly recommended!). The basic idea is to write three pages every morning, first thing, as fast as you can with no editing and no judging, just pouring out the words, even the words are “I can’t think of anything to write.” More often though, the words will eventually start coalescing around a topic, often the topic about which you are blocked. At least, that’s my experience. Cameron describes morning pages as three pages, handwritten. I typically do my morning pages on an awesome website called 750words.com – three pages handwritten is about 750 words – which tracks my writing over time, and makes it fairly easy for me to reuse it if I come up with something good (which often happens). The site has a number of “gamification”-like features, like giving you badges for streaks of different lengths. I’ve now added my own challenges, such as attempting to write 1,000 words or more per day on average. I find that my creativity really starts to kick into gear, if it’s going to, between 600-800 words, and if things start rolling, it’s pretty easy to get up to 1,400 words in a sitting.
2. Related to morning pages is the timeless advice from Anne Lamott, in her book Bird by Bird – “Write sh*tty first drafts.” Or as I like to clean it up a bit – Write crappy first drafts. This is actually not a directive, it’s just a fact that your first drafts will not be what you want them to be, and so you should expect that and not get worried when your first attempt is a piece of crap. What’s amazing is that you can attack that first draft, and turn it into a second draft, and it’s likely to be a lot better, and the draft after that even better. And even if the first draft doesn’t lead directly to a second draft, at least it will help you think through your idea so that you can create another (but less crappy) first draft in a different direction, but with much more knowledge about the landscape of the idea.

   The two techniques above are focused on writing, but you can use them for any creative effort. I often will do something like crappy first drafts for UI concepts. I don’t expect to do a good job of user experience design on my first mockup, but I always learn a lot and at worst I get a sense of what additional things I need to start thinking about in order to make a better experience.

3. Finally, “use your obvious.” This is a new technique for me, which I got from a great list of nine creativity sparking tips from Marelisa Fabrega (I was turned on to this list by Kate Matsudaira (@katemats) in her excellent Technology Leadership News newsletter). I find it incredibly useful. The basic idea is that what is obvious to us about a particular situation is not necessarily obvious to other people. In fact, that what’s obvious to us is actually our differentiator, to use a very product-management word, it’s why we got the job in the first place. The way I use this is to just write down what’s obvious to me at first. That might be innovative enough, and it’s certainly a good start. To provide value I don’t have to necessarily invent something new – I just need to get my own insight into the world.

Coming up – PM-specific creativity unblockers

I will continue this series tomorrow with some more product management-specific techniques for overcoming fear and creative blocks. Let me know in the comments how you handle creative challenges in your work, whether it’s coming up with new product ideas, or designing UIs, or writing marketing material. 

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?

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.

Therefore, as a product manager, I’m have to be more concerned about the customer’s experience than the company’s short-term desires, especially about release dates. The company might want a release to come out on a particular date, but if it will jeopardize an important customer’s experience, I can’t allow that to happen. And in the end, the customer is more important. Losing a customer is very costly, while shipping a few weeks late to make sure a product is actually ready is not very costly. It does impact the schedule of the next release perhaps, but less than the fire drill of the emergency fixing of bugs you actually shipped.

I’m interested to hear your thoughts on this – do you sacrifice schedule for quality, or have you managed to figure out how to drop features for time?