Sep 16

Product Management And Fear – Three More Powerful Creative Blockbusters

Several years ago I had an article about three powerful tips for getting through a creative block. Although focused toward product managers, the tips were 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!”

At right around the same time I drafted this post with more tips that are especially applicable to product managers. But I just found out I never posted it! So here it is, a little late, but still pretty useful, I’d say. (Well, I still use these techniques anyway!)

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.”

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 often frees 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 the previous 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 help you create 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, 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 and how it fits into the process flow in the application. We can 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.

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 not only the problem we’re trying to solve, but also how the solution might come together. They are great for addressing the -ilities like usability and scalability.

I created a mind map template to help me with user experience and interaction design aspects of my features. My template 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). I use the mindmap to make sure I have good answers to every aspect as I’m designing the feature.

Next Up – PM-specific Tools, Not Just Techniques

In this article I focused on techniques that are well-suited to product management’s multiple modalities. A later 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.)

Jan 14

5 Surprising Ideas That Will Make Customers Love Your Products

The other day someone asked me “how do I position my new enterprise software product for each of the three buyer types – user, buyer, and decider?” We had a half-hour discussion about this. It boiled down to a set of ideas, some of which I’ve talked about on the blog already, that comprise a powerful set of tools to help you think through your product offer, value proposition, and positioning.

  1. Goal-directed design – If your product helps users address their personal goals (“don’t let me look like an idiot,” “don’t make me do stupid stuff over and over again,” etc.), not just their practical goals (“getting the job done”) they will love it. (This concept is from Alan Cooper’s awesome The Inmates Are Running the Asylum – a must-read for anyone interested in making usable products that customers love.
  2. Order-of-magnitude rule – You have to find a way to describe your product as 10x better than what they currently use, otherwise it’s not worth it to them to buy and switch from the status quo.
  3. Core-vs-context – Context is what all the products do in the category. Core is what differentiates you from other products in the category. Your product has to deliver the context – these are “table stakes”. You have to have some differentiators, otherwise why would people buy your product instead of your competitors’?
  4. Process fit – There’s a process before yours that is feeding your product. There’s a process after yours that your product feeds. You must ensure your product can connect to the preceding and subsequent processes
  5. Build in knowledge – Customers are looking to vendors for knowledge, not capabilities. If you add knowledge into your product, it’s 90% likely to be a differentiator.

These five key ideas will help you validate your product idea, ensure users love your product, and beat competitors. 

May 13

Good Metaphors Improve the Usability Instincts of Your Developers

Good software is a meal, not a kitchen

When you go to a restaurant and order a dish, you expect the chef to make a dish that’s ready to eat, without you having to specify anything. And generally speaking, that dish is going to work out great for you. Sometimes you might be on a low-carb diet, and you need to ask them to “hold the bun” or something like that (understanding that the chef might not be able to accommodate you). But normally, the chef sends you something good and you eat it, and you don’t need to make any modifications in its configuration.

That should be one of the goals of our software as well. The user should be able to “order” a feature or function in the software, and the software goes ahead and does that feature or function in the right way that will make the user happy and solve the problem and create business value. If the user has to make some modifications to their order, they can, but those changes should be the exceptions, not the rule.

Developers like making stuff, so they give their users kitchens

The natural inclination of software developers, though, is to make software that’s highly configurable, where the user has to make a lot of decisions every time, and the software itself makes as few commitments as possible as to what the “right” way is. Or, to use my metaphor, it’s as though the software is making the user a chef, and providing a full kitchen, rather than taking on that responsibility in the software and allowing the customer to enjoy to well-prepared dish.

I find myself coming up with these stories, like comparing our product to a restaurant, to give the developers tools for thinking about the software in ways that will help them make good decisions about usability without my help. Of course I want them to come to me when they have questions, but by giving them better instincts on usability – and metaphors are a good way to do this – they are much more able to come up with good solutions themselves.

What are some of your favorite metaphors for improving the instincts of your developers? By the way, a hat tip to Alan Cooper (@mralancooper) who used another restaurant metaphor – about an excellent waiter – to talk about software politeness.