Linds Redding’s A Short Lesson in Perspective is essential reading for anyone in the creative industry – particularly those who make things for the web. He laments the loss of time to think and reflect about designs before they go out the door:

Pretty soon, The Overnight Test became the Over Lunch Test. Then before we knew it, we were eating Pot-Noodles at our desks, and taking it in turns to go home and see our kids before they went to bed. As fast as we could pin an idea on the wall, some red-faced account manager in a bad suit would run away with it. Where we used to rely on taking a break and “stretching the eyes” to allow us to see the wood for the trees, we now fell back on experience and gut feel. It worked most of the time, but nobody is infallible. Some howlers and growlers definitely made it through, and generally standards plummeted.

It’s a strikingly honest essay about the creative process and the pressures of working on the Internet today.

I have a feeling that we live too much of our lives through other peopl’s eyes. It seems as if w’ve changed our definition of what is worthy and real to accommodate an economy based on the currency of sharing. It’s an economy that measures an event’s value by the number of likes and retweets it gets. An economy that changes our decision-making because we start to seek out the things that have the highest “sharing value”, while we shun the quiet, everyday activities that make up a life.

As I graze through my Facebook feed tonight, I munch on the extraordinary and exciting lives of others. A live performance in San Francisco. A hike in Cape Town. A business success in Miami. A funny and clever thing someon’s son said. And of course, the photos. The endless, happy photos of dancing, mountains, wine, exotic travels, more wine, and lots and lots of babies. Everyone is having an amazing time in an amazing world.

Twitter shows me something slightly different. I see people who are drowning in success and ambition, and I can’t help but envy them. Through Twitter I see how smart everyone else is. And as inspirational as that is most of the time, I sometimes look at how high the bar seems to be set and then I just want to sit down and rest for a while.

Everyone knows that’s not the whole story, of course. No one says “I’m lonely” on Twitter. No one uses Facebook to post their deep, dark thoughts about marriage or parenting or work or the future or the past. We all know it’s not real but we have to keep up the facade. If one of us were to break down, we would all lose the ability to believe we are who we pretend to be, and that’s not something w’re prepared to do.

Maybe it’s time for a change. Maybe it’s time to stop consuming so much of other peopl’s perfectly manicured public lives, and start producing just a little bit more. I wonder what would happen if we measured the value of an activity not by how great the photo opportunity would be, but by what value it would add to those we’re with – our family and friends.

I guess I’m just worried that if I keep looking at my life through other peopl’s eyes, I might go blind to the things that really matter.

Ryan Singer wrote a very clear and succinct definition of Product Management in Advice for product managers:

“Managing the product” means deciding what we do to the product and then making it happen.

When you unpack that, it involves strategy (what is important to do?), resources (how much time can we spend on it?), managing development (what do we need to build in order to do it?), managing experience (how will it look and work, how does it integrate into what we already have?). And all of it with regard to the bottom line of the business. Given a strategy, resources we have, a user experience bar to uphold “” given all that, what can we do and why is it worth doing?

It’s a great primer for anyone who wants to understand what PM’s do – especially for people who are considering making a career change to Product Management. There’s one part I’d like to unpack a little more, and that is prioritization. Ryan touches on it as follows in a section entitled “Deciding what to do”:

I try to lead every decision with user experience. What is the user-facing situation we want to change? Or if the motivation isn’t because of a user benefit, but a pure business reason “” what is the impact on the user, and how can we align incentives so this at minimum makes sense to the user? This is critical.

He advocates for “leading with design”, which is a sentiment I wholeheartedly agree with. But how does this work in practice, particularly in large organizations with a variety of product lines and a gazillion stakeholders? We’ve spent a lot of time trying out different ways to solve the problem of prioritization, so I naturally gravitated towards that section in Ryan’s piece, and hoped for a little more detail. Ryan, if you’re listening – I’d love to see a follow-up post where you explain your process a bit more.

This is important because I believe the hardest part of a Product Manager’s job is answering the strategy question that Ryan uses in his definition: What is important to do? Once you know what to do, the how isn’t necessarily easy, but you’ve at least started the race and you know what you’re running towards. You’ll work with developers to understand technical requirements. You’ll work with designers and guide them through a user-centered design process. Running the race is the fun part. Deciding which race to run is the excruciating part, and it makes or breaks a product.

How others prioritize

There are many established processes for product prioritization, and we’ve tried most of them on the various teams I’ve worked with. I’m particularly interested in methods that can be used on an ongoing (daily/weekly) basis – not ones that are used every few months for long-term planning. The KJ-Method has a lot going for it:

The KJ-Method is a fascinating mix of independent brainstorming, group dynamics, and democracy. It allows a team to be creative and critical in a productive manner, where strong personalities and politics play second fiddle to the independent perspectives and experience of the team.

Jared Spool claims that he can do this process in under an hour with a team, but my theory is that he can only do that because he is superhuman. I find the 8-step process a little too heavy and time-intensive for day-to-day use. It’s great for longer-term strategic planning though.

The Kano Model is another great technique for prioritization:

The easiest way to think of the model is on a two-dimensional grid.

The horizontal axis represents the investment the organization makes. As investment increases, the organization spends more resources on improving the quality or adding new capabilities.

The vertical dimension represents the satisfaction of the user, moving from an extreme negative of frustration to an extreme positive of delight.

As much as I like this model, it suffers the same downside as the KJ-method – it’s too time-intensive for ongoing prioritization. And then there is Amazon’s approach, which is based on the following principle:

Prioritize themes, not projects – Create a list of themes for your product or business. Examples might be customer acquisition, activation, retention, avg revenue per user, avg visits per user, etc. Pick ~3 that are the most important for your product given its stage.

The gist is that they prioritize based on a project’s potential impact vs. cost:

Look for the projects with the greatest projected impact with the least cost, and do these ones first, quickly. Then move on to the next projects, or the next phases of the early projects that had a greater than expected impact.

How we prioritize

I’ve found a stripped-down version of the Amazon method most effective and realistic in our organization. As much as I agree with the principles of each of the three approaches mentioned above, they tend to be unrealistic in the context of ongoing prioritization. So here is the extremely simple process we’ve used on an ongoing basis, with good results:

1. Have a white board with a permanent two-by-two matrix on it. The horizontal axis represents Business impact (which includes user needs and technical considerations), and the vertical axis represents Level of effort to implement (which includes people and their time commitment).
2. Write product requests and ideas on sticky notes as they come up, have a quick discussion with relevant people to ascertain business value and level of effort, and then put the sticky note on the two-by-two matrix.
3. Write prioritization numbers next to each of the features/themes, starting with those that have the highest business value. I like a 70/30 split between high effort / low effort features, but that’s a theory for a different post.
4. Every week or so, check your roadmap to make sure you’re still working on the right things, and make adustments as needed.

It’s a simple method, and it’s far from perfect. But it has a few things going for it:

• It’s detailed enough to ensure constant prioritization based on what’s important.
• It’s light enough to make it practical for everyday use.

PM’s should spend most of their time managing experience and managing development – two of the activities Ryan points out in his post. I’m sure they don’t skip over the prioritization part at 37signals, but I wanted to give some more context around that because it’s something I struggle with a lot, and I guess I hope I’m not alone. Actually, I know I’m not alone. If we all knew what was important to work on, there would be no failed products.

Jake Knapp writes that you can build better products by designing the marketing first:

Okay, let’s pretend I grab you and stuff you in a DeLorean. We time travel a few weeks into the future. Your latest project has just been released.

Imagine you can see the launch page. It has a nice simple headline explaining the appeal of your product, with a couple of secondary call-outs. You print the screen, hop back in the DeLorean, and return to the present.

With this glimpse of the future in hand, your team will be better at focusing on the core of the product. If it’s on the launch page, double down! If it isn’t, think hard before spending any time on it.

That reminds me of a similar technique used by Amazon called “working backwards”. It’s outlined in this Quora thread:

For new initiatives a product manager typically starts by writing an internal press release announcing the finished product. The target audience for the press release is the new/updated product’s customers, which can be retail customers or internal users of a tool or technology. Internal press releases are centered around the customer problem, how current solutions (internal or external) fail, and how the new product will blow away existing solutions.

Once the project moves into development, the press release can be used as a touchstone; a guiding light. The product team can ask themselves, “Are we building what is in the press release?” If they find they’re spending time building things that aren’t in the press release (overbuilding), they need to ask themselves why.

These are both great techniques to prevent scope creep and ensure that you’re building products that have clear user benefits.

Rabbit holes: Why being smart hurts your productivity is a great post on staying focused without losing the value of going down intellectual rabbit holes:

The names change but the story remains the same. Designers find themselves studying fancy, new CSS3 effects when they should have been wire framing their checkout page. Hapless students find that they are on the Wikipedia page for Esperanto instead of writing notes on Norse mythology. Like Alice led into Wonderland by the White Rabbit, geeks too easily fall into “the rabbit hole”.

I won’t spoil the suggestions for you. See also: The potential and dangers of “˜squirrel projects’.

(via Brad Whittington)

This is my contribution to Chris Shiflett‘s Ideas of March initiative, which encourages people to write about why they like blogs.

My love of writing comes from a love of problem-solving. There is a sense of pride and accomplishment in finding the right words to say something. And yet, great writing has an inherent unattainability to it that keeps me ever searching. There are good ways and bad ways to communicate something, but there is never a best way. It’s like a video game in the sense that you can level up by writing often, but it’s not a game you can ever beat. There is no big boss fight at the end that proves that you are now the best writer you can be. What keeps me going is the nagging sense that the last thing I wrote could have been written much better, so I’d better keep trying.

There are many benefits to writing, of course. Most importantly, it’s a problem solving technique in itself. By taking the time to structure your thoughts and your words in a way that other people need to understand, you tend to get a better understanding of what’s going on in your head. Clive Thompson addresses this well in The art of public thinking:

The process of writing exposes your own ignorance and half-baked assumptions: When I’m writing a Wired article, I often don’t realize what I don’t know until I’ve started writing, at which point my unanswered questions and lazy, autofill thinking becomes obvious. Then I freak out and panic and push myself way harder, because the article is soon going before two publics: First my editors, then eventually my readers. Blogging forces a similar clarity of mental purpose for me. As with Wired, I’m going before a public. I’m no longer just muttering to myself in a quiet room. It scarcely matters whether two or ten or a thousand people are going to read the blog post; the transition from nonpublic and public is nonlinear and powerful.

Writing in public continues to help me gain clarity about my thoughts and problems. That I expected. But I didn’t expect it to give me such a sense of community. The past few months have been especially gratifying, ever since I’ve been invited to become a contributor to Smashing Magazine. Through that process I’ve met amazing people, and through them, I think I’ve become a better writer. Which in turn helps me to solve problems better. It hardly seems fair that I gain so much from this community. If you’ll allow me the use of a ridiculous phrase, the ROI on my writing seems preposterously high.

I started my first blog on Windows Live Spaces in 2003. I’d just moved to the US and needed a way to feel connected to friends and family in South Africa. It’s 2012 now, and I don’t write on Windows Live Spaces any more. I also don’t live in the US any more. I’ve moved homes and countries and blogging platforms way too many times over the past 9 years. But looking back over many false starts and wrong turns in life and in blogging, I’m grateful for the thread of words that runs from my beginnings on Spaces, through the detour on Blogger, and now my own home on this domain. Somehow, those words anchor me.

So maybe writing this has once again shown me the error in my original thinking, just as it’s done so many times before. I was wrong in my opening paragraph. I don’t write because I love problem-solving. I write to know that I am here.

This is a great interview with The Bad Plus. They talk about Jazz and finding your voice, but it’s this part on humility that stood out for me:

I prefer to think that it’s possible to always sort of double-check yourself and be like, “Is this really the right thing?” and be searching.  The classic jazz example is John Coltrane: consummate musician, but really never stopped searching. I don’t think he ever believed the hype about himself.  He could’ve been like, “Man, I got it, I’m great.”  But that’s not the feeling you get. Coltrane was incomparably great, but he was also just humbly trying to figure it out.

This should always be our attitude when we design as well. If we think that we’ve figured out how people use computers, or exactly how human psychology works, or that we can design the perfect, seamless experience – then we tend to start designing for ourselves at the expense of our users. Never stop searching.

See also: Humble Design.

Readability recently released their new iOS app to lots of positive reviews and public declarations about “finally” being able to switch from Instapaper. For all I know Readability is a superior product, but I haven’t even considered moving away from Instapaper. I have no desire to investigate the new app. So either I’m crazy, or it’s indicative of a shift in how we view software – a shift towards the human connection that underlies everything we do online. Let me explain.

I’ve been using Instapaper for a long time, the last few months as a paid subscriber. But that shouldn’t actually count for anything. The switching costs for “Read Later” apps are low. It might be uncomfortable to have two distinct reading lists for a week or so, but after one list dies down and the other one picks up, everything would go back to normal. In most cases you can import your data into a new service, so you don’t have to lose any historical data. So if switching costs are low, and Readability could very well be a better app, why am I not interested?

My loyalty comes from the fact that I’m unable to separate Instapaper from its creator, Marco Arment.

Marco does something really smart that gives him a big advantage over the makers of other, similar apps: he makes himself extremely visible. But even more importantly, he does so as himself, with his own personality, as opposed to some tightly controlled and measured “social media brand engagement” thing.

His blog is required reading on all things from tech to coffee to headphones. I hear his complaints every week on the Build & Analyze podcast with Dan Benjamin. So, yes, it feels like I know Marco (don’t be creepy). Sure, I disagree with his opinion on cars, and I feel like he’s a little bit harsh on Nest. But that’s part of what makes Instapaper a unique app. Its creator is a real guy I can relate to, albeit in a sometimes frustrating way because his opinions are SO WRONG SOMETIMES.

Instapaper is one of only a few apps I can think of where I know the developer’s name, and actually know a little bit about them based on their online presence. Pinboard is another one. So is nvALT. But those are exceptions; in the majority of cases I don’t know who the developers of the apps I love and use every day are. I’ve now come to realize that it’s no coincidence that I have no intention of switching away from any of the apps I mentioned above. But if a better RSS reader than Reeder were to come along, I would most certainly investigate.

If there’s a point to this story, it’s this. We’re entering an era where software is personal. By now we’ve all gotten over the initial shock of how the Internet can remove geographical barriers and turn us into one big happy, arguing family. We’re coming to terms with the fact that the Internet is people all the way down^[1]. So now we can start to figure out what that actually means. I think it means that we’re going to pay increasingly more attention to the people who make the things we use, and their personalities will become inseparable from their work. Loyalty will come from our relationships with people, not things.

Which is why I’m sticking with Instapaper.

1. Frank Chimero in Issue #1 of The Manual ↩