Assume You Don't Know Jack

Very early in my career, I was on a phone interview for a product management role. I thought it was going well overall – we had a good rapport, I highlighted some achievements I was proud of and even gave them some ideas for their business I had uncovered in my research. Then came a no-brainer question that I was ready to knock out of the park.

Can you describe a product or experience you love, and why you love it?

Just one product? Easy! I have dozens. I live for technology. I make it a habit to see every new consumer product, every new programming framework, every new blog post I can find to add to my internal map of the digital world.

But I blew it. Not at first, though. Describing why I loved this product was easy. I articulated my points clearly and considered the broader applications and lessons. Then the interviewer asked a simple follow-up.

 Continue Reading    

Desire Path Design

Desire paths. I’ve seen them, and used them, and contributed to them countless times. Yet I never knew they had a name.

A desire path (also known as a desire line, social trail, goat track or bootleg trail) can be a path created as a consequence of foot or bicycle traffic. The path usually represents the shortest or most easily navigated route between an origin and destination. The width of the path and its erosion are indicators of the amount of use the path receives. Desire paths emerge as shortcuts where constructed ways take a circuitous route, or have gaps, or are lacking entirely.

That’s the Wikipedia definition. It’s the place where the expectations of a community conflict with the expectations of a design. Almost always, the community wins. The people win. Without significant enforcement costs, design alone will not dictate what people will do.

Smart urban planners use this to their advantage instead of fighting against it. In the most extreme form, they’ll build as little as possible when starting, and use the emerging desire paths to inform the build-out. In a more common form, they look to these paths when designing future improvements and renovating existing spaces. Smart product development teams can also incorporate this thinking into their own practices.

 Continue Reading    

Continuous Deployment & Customer Expectations

Steve Blank has a new post up on the downsides of continuous deployment. As always, it’s a great read.¹ I don’t want to give away the details, or the great examples he uses, but here’s the basic gist of his post.

In the old model of waterfall product development, customers had bounded expectations about what they were buying. Once a quarter, or once a year, or every few years a new product would be released. The features would be set in stone – for good or for bad. Customers knew what they were getting and grew accustomed to that exact product with that exact feature set.

It can be harder to manage customer expectations in the brave new world of continuous deployment, where a product is never finished and a feature set never set in stone.

 Continue Reading    

Using the Kano Model in Product Management

Regardless of the specifics of your domain, the Kano model is a good theoretical framework to start with when looking to delight users. In its simplified form, it divides features into three categories:

1. Basic Expectations

   These features are required for any level of satisfaction but will never delight or increase satisfaction - at their worst they are dissatisfaction drivers and at their best they are only neutral.

2. Performance Attributes

   These features drive value when done well and detract value when missing or done poorly - these typically make up the bulk of a product’s feature list and serve as the basis for marketable value

3. Excitement Generators

   These features drive excitement and delight when present but cause no dissatisfaction when missing - since they are not expected they are often considered remarkable

 Continue Reading