Jeff Atwood starts his article This Is All Your App Is: a Collection of Tiny Details as a post about cat feeders, but stick with it. It’s gold:

Getting the details right is the difference between something that delights, and something customers tolerate.

Your software, your product, is nothing more than a collection of tiny details. If you don’t obsess over all those details, if you think it’s OK to concentrate on the “important” parts and continue to ignore the other umpteen dozen tiny little ways your product annoys the people who use it on a daily basis ”“ you’re not creating great software. Someone else is. I hope for your sake they aren’t your competitor.

Jason Fried in Why is Business Writing So Awful?, a good post on caring about the words you use to describe your product:

Unfortunately, years of language dilution by lawyers, marketers, executives, and HR departments have turned the powerful, descriptive sentence into an empty vessel optimized for buzzwords, jargon, and vapid expressions. Words are treated as filler - “stuff” that takes up space on a page. Words expand to occupy blank space in a business much as spray foam insulation fills up cracks in your house. Harsh? Maybe. True? Read around a bit, and I think you’ll agree.

If you’re involved in any kind of software development work, I highly recommend the Harvard Business Review article Six Myths of Product Development (it’s paywalled, but keep reading”¦). It details 6 common misconceptions of most product development managers:

1. High utilization of resources will improve performance.
2. Processing work in large batches improves the economics of the development process.
3. Our development plan is great; we just need to stick to it.
4. The sooner the project is started, the sooner it will be finished.
5. The more features we put into a product, the more customers will like it.
6. We will be more successful if we get it right the first time.

The authors detail the effects of and possible solutions to each of these fallacies. Here’s an excerpt from the resource people utilization section:

In both our research and our consulting work, w’ve seen that the vast majority of companies strive to fully employ their product-development resources. The logic seems obvious: Projects take longer when people are not working 100% of the time””and therefore, a busy development organization will be faster and more efficient than one that is not as good at utilizing its people.

But in practice that logic doesn’t hold up. We have seen that projects’ speed, efficiency, and output quality inevitably decrease when managers completely fill the plates of their product-development employees””no matter how skilled those managers may be.

Unfortunately the full article is behind a paywall. You can read the whole thing if you haven’t hit your 3-articles-per-month quota yet (sigh”¦). Or you can download this PDF I made of the print view.

Andrew Chen wrote a very interesting piece called The Law of Sh-tty Clickthroughs. I recommend you read the whole thing before continuing here. Chen goes into great detail to explain just how ineffective banner ads and other marketing methods have become, and he gives some very astute reasons for why it’s happening:

Customers respond to novelty, which inevitably fades.

First-to-market never lasts.

More scale means less qualified customers.

In short, I loved the article. All the way to the last section. Here is Chen’s proposed solution to the problem:

The real solution: Discover the next untapped marketing channel

The 10X solution to solving the Law of Sh-tty Clickthroughs, even momentarily, is to discover the next untapped marketing channel. In addition to doubling down on traditional forms of online advertising like banners, search, and email, it’s important to work hard to get to the next marketing channel while it’s uncontested.

This is certainly a solution to the problem, but I think there’s a better one: Make an excellent product, and then support the crap out of it. I guess I’m suggesting that we’re entering a post-marketing world where people don’t care about how companies tell them they should feel. In response, we need to shift our focus away from traditional channels to focus on what’s really important: the thing we’re making.

Instapaper is famous for doing no marketing, and yet it’s an enormously successful app. The popularity of Sparrow seems largely due to unsolicited reviews and good word of mouth. Amazon.com has become the de facto place to get user reviews and do price comparison shopping - I’d argue that keeps them top-of-mind more than traditional marketing does.

The lasting benefits of “Word of Mouth” have long been acknowledged, but recently that worthy goal has been derailed by a frantic quest for the short-term benefits of “going viral”. The term “viral marketing” is presumably used without realizing the irony that viruses”¦ you know”¦ kill people.

So I’m not saying that you should try to make a video that millions of people watch on YouTube. I’m saying that there is indeed a formula for effective marketing, and it relies on an unending supply of good will from customers. The formula is quite simple, but unfortunately there are no shortcuts. It looks like this: make great products, sell it to people, support it well, and be patient.

And here’s the beauty of this strategy. This “marketing” method isn’t susceptible to all the issues that give traditional marketing channels such a short shelf-life of effectiveness:

• The novelty of a good product that keeps getting better doesn’t fade.
• There is no first-to-market messaging advantage to lose, because your focus is on the product, not the message.
• And finally, more scale means more and more people to talk about your product.

The other benefit? If the product fails, it will fail for the right reason: it’s just not good enough. Which gives you more time to focus on the next product that will be good enough.

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.

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 ↩

Yesterday saw the Beta launch of a new Mint.com-type startup in South Africa called 22seven. They’re essentially aiming to give people better insight into the money they spend, and help them make better decisions about that. Or to put it in their own words:

We use smart information-gathering technology so our users can see all their financial stuff in one place. W’ve applied insights from behavioural economics so our users can better understand the way they think. And by employing principles of play, our users become more engaged, and more willingly engaged, with their money.

It didn’t take long for the banks to start freaking out about the security implications of giving your banking credentials to a third party, but there have also been some defenses of the safety of the service. Instead of rehashing those arguments, I’d like to make three quick comments about the new service.

An observation

I’ve been watching this unfold with fascination over the last 24 hours. Everyone who attended the launch event in Johannesburg seemed really impressed, but it didn’t take long for some (legitimate) concerns to arise as people started trying out the service:

My mom told me never to accept sweets from strangers and to give out my pin number… So… Yeah… Sorry 22seven…

”” Cathryn Reece (@CathrynR) January 26, 2012

That’s a sentiment I agree with, but things started to go downhill a bit from there as the tweets became more and more negative. We’re a finicky bunch of complainers, aren’t we! But as I caught myself just in time before getting sucked into the negativity vortex, a phrase jumped into my head: Schlep Blindess. As in - these guys don’t have it. In Paul Graham’s excellent essay he describes schlep blindness as the inability to identify hard problems to solve:

The most dangerous thing about our dislike of schleps is that much of it is unconscious. Your unconscious won’t even let you see ideas that involve painful schleps. That’s schlep blindness.

He ends his essay by explaining how to avoid schlep blindness:

Some ideas so obviously entail alarming schleps that anyone can see them. How do you see ideas like that? The trick I recommend is to take yourself out of the picture. Instead of asking “what problem should I solve?” ask “what problem do I wish someone else would solve for me?”

And that’s why I admire the creators of 22seven. They’re working on a problem we all want solved, but most of us are too scared to work on. And for doing that, they deserve enormous credit.

A complaint

Speaking of finicky complainers, can I be one of those for a minute? Ok, cool. Obviously my first instinct was to scrutinize the design of the site, and even though there’s a lot to like about it, I have to mention a couple of things that I believe are not implemented correctly from a UX Design perspective.

First, forcing someone to wait for a Flash (!!) animation/introduction to load when they click “Register” is just not a good thing. Users don’t have patience for that stuff. If I ask for a registration form, my expectation is to see a registration form immediately. But my main beef is with the registration form itself:

Here are some of the issues:

• The text has very low contrast with the background which makes it difficult to read. Come on, everyone - join the contrast rebellion!
• We know that it’s bad to use multi-column layouts in forms.
• Speaking of contrast, what stands out are the phrases “About you”, “terms of service”, and “privacy policy”, while the primary call to action (“Yes, I do”) is a grey button on a dark grey background.
• While I’m nitpicking, if the button says “Yes, I do”, shouldn’t the title be “About me”?

We just don’t have to re-invent forms any more. The hard work has been done for us - we know how forms should be designed. And I don’t want to get into the Flash debate again, but why build this thing on a waning technology when you can build a responsive HTML web app that works on all devices?

A suggestion

Lastly, I’d like to offer a suggestion. If it is indeed true that 22seven has not met with South African banks yet, that’s a situation that should be rectified soon. In fact, my suggestion is that 22seven meets with one bank and work with them on an API solution that will allow them to access users’ banking information without having to store their credentials at a 3rd party. That’s what OAuth is for. And based on everything we know about Michael Jordaan (the CEO of FNB), wouldn’t FNB be the perfect bank to partner with on this? Once they’re on board, and FNB’s handsome and smart clients start using the service, the other banks are sure to follow.

I’d like to end where I began - on a positive note. I’m truly grateful that 22seven is tackling the banking/money management problem in South Africa in a very real and committed way. I think they vastly underestimated the backlash they would get from users when they’re suddenly asked for their online banking credentials (otherwise the web site would have been littered with trust-building explanations and images). But that’s a fixable problem, and so is my UX nitpicking - they’re not difficult issues to address.

So despite my complaining, I’m extremely excited about 22seven, and I’m rooting for them to succeed. I hope you’ll join me.

In 1955 David Ogilvy wrote a fascinating letter about his habits as a copywriter. One of his points jumped out at me:

I write out a definition of the problem and a statement of the purpose which I wish the campaign to achieve. Then I go no further until the statement and its principles have been accepted by the client.

This is applicable to design projects as well. If clients (internal or external) ask us for some quick wireframes, it is our responsibility as user experience designers to push back and make sure everyone agrees on the problem and the goals of the project first - before the design cycle starts. It sounds so obvious, but I see people falling into this trap all the time.

The product discovery process can take months, weeks, or even a few hours if there are tight deadlines. But it cannot take zero hours - that’s a recipe for disaster.

Fred Wilson on what’s needed to build product in the early stages of a startup, in The Management Team While Building Product:

Building product is not about having a large team to manage. It is about having a small team with the right people on it. You need product, design, and software engineering skills on the team. And you need to be focused, committed, and driven. Management at this point is all about small team dynamics; everyone on board, working together, and getting stuff done. Strong individual contributors are key in this stage. Management skills are not a requirement. In fact they may even be a hindrance.

Startup teams always have software engineering skills on board from the very beginning - as they should. But too often you see marketing and business development skills being added before you see product/design skills. This leads down a dangerous path that too often ends in a catastrophic lack of product/market fit.