Two articles on company culture caught my eye last week, both about what it’s like to work in organizations with no formal structure and communication. First, from the always excellent Design Staff, Design at Valve: collaborating and innovating in a flat organization is an interview with one of the designers at Valve:

It’s everyon’s job at Valve to recruit peers to help ship an idea. If I’m unable to recruit an engineer to help me ship an idea, it probably means either the idea isn’t solving an important problem, or it’s just not timely given our current priorities and ongoing projects. As individual contributors, w’re each constantly asking ourselves “Where is my time best spent?” The answer changes as projects ship and as new opportunities emerge.

For these self-selecting project teams to work, it’s important that we keep up on the various efforts happening around the company. Ther’s no top-down communication, so this typically happens by chatting with one another over lunch, or checking in with people to learn what’s happening.

Second, Brandon Keepers wrote about what it’s like to work at GitHub, and it struck me as remarkably similar to Valve’s culture:

Anarchy works wonderfully in a small group of individuals with a high level of trust. Everyone at GitHub has full access and permission to do whatever they want. Do great things and you earn respect. Abuse that freedom and you violate everyon’s trust.

Each person at GitHub has the responsibility to sell their ideas to the rest of the company. I quickly learned that if I can’t get anyone else interested in the project that I want to work on, then either I poorly articulated my vision, or more likely, it does not benefit the company. You can still work on it, but you will likely be working alone.

Both posts are worth reading, because they also explore some of the challenges of working in such environments. The teams seem well aware of the downsides of the cultures they’ve created, and they’re working hard to address those because the upsides vastly overshadow the downsides for them. And I guess that’s the key phrase — for them. I don’t think this type of environment will work in every company, but it’s encouraging to see how systems based solely on trust and self-governance can create productive environments and (extremely) happy employees.

For both companies, the measure of success is the quality and value of the products they ship to customers. That is fantastic, and could be the beginnings of a new era of true user-centered organizations. We need more experimentation that does away with conventional hierarchies and corporate structures so that we can find new ways to create value for our users.

I like this mental image of the “product in search of a solution” phenomenon we see so much of of these days:

Your organization invents something no one else does. The rest of the process goes like this: I have this tail. I put it on the donkey. I spend money testing and fixing the tail to get it closer to what the donkey wants it to do. I also spend money on marketing and sales people to convince the donkey I have what it needs.

There is, of course, a better way.

I was encouraged to read these words by Matt Mullenweg in his post Radically Simplified WordPress:

As John Borthwick put beautifully today, “A tablet is an incredible device that you can put in front of babies or 95-year-olds and they know how to use it.” How we democratize publishing on that sort of platform will not and should not work like WordPress’ current dashboard does. It’s not a matter of a responsive stylesheet or incremental UX improvements, it’s re-imagining and radically simplifying what we currently do, thinking outside the box of wp-admin.

This is great news, and I’d like to offer my 2 cents on what an ideal mobile WordPress platform might look like. Because despite several attempts I haven’t been able to figure out a good workflow for publishing to WordPress from my iPhone or iPad.

Let’s take this post as an example. I read Matt’s article in Instapaper. I used the awesome “Create Note in Simplenote” feature to send the above quote to my preferred writing app. I am writing these words in Simplenote for iOS using Markdown. Writing down the words is a breeze; geting those words to my blog is a mission (and usually results in a big time delay). I’m going to wait until I get home, open my laptop, and wait for nvALT to sync with the text I entered into Simplenote. Then I’ll copy the Markdown into MarsEdit, add some URL and keyword specifics, and hit Publish.

The WordPress iOS apps are not helpful to me, because they don’t allow you to add custom fields and URLs. For example, for link posts I have a custom field that turns the title of the RSS entry for that post into a link that takes the reader directly to the original article. I can’t do that in the iOS app.

But here’s the thing - I don’t want a better WordPress iOS app. I don’t even want a mobile-optimized WordPress Dashboard. Instead, I want all the apps I already use to integrate seamlessly with the WordPress backend. So my ideal mobile WordPress experience is this: make it dead easy for text editor apps to publish to WordPress.

Once I’m done writing this post in Simplenote I would like to tap a link that says “Publish to WordPress.” I would then like to see a customizable dialog that lets me add/edit all the fields I have chosen to include, hit Post, and be done. It could work similar to Tumblr integration on Instapaper, except with customizable fields:

Maybe this is already what the WordPress team is thinking about - I certainly hope so. Either way, I know that this kind of seamless integration would truly free us to publish from anywhere, and will put a final nail in the coffin of the “iPad is only for consuming” argument.

It would be great to get more insight from the WordPress team on what they’re working on for mobile.

This story has been passed around quite bit, but in case you haven’t seen it, Mat Honan’s How Yahoo Killed Flickr and Lost the Internet is a fascinating story:

This is the story of a wonderful idea. Something that had never been done before, a moment of change that shaped the Internet we know today. This is the story of Flickr. And how Yahoo bought it and murdered it and screwed itself out of relevance along the way.

It’s a well-written and thoughtful account that’s well worth the (long) read. Honan’s core argument on what went wrong is this:

All Yahoo cared about was the database its users had built and tagged. It didn’t care about the community that had created it or (more importantly) continuing to grow that community by introducing new features.

All the wrong decisions that Yahoo made can be traced back to that single issue: that they didn’t understand why people use Flickr. Instead, they made the common and fatal mistake of placing profit before product.

Unrelated, but until I read this article I had no idea that there is an app that adds cats with laser eyes to your photos. That is awesome. And now I’m really going off on a tangent, but there is a certain poetry to this 1-star review of the app:

It only gives you a small amount of cats to choose from and if you want another small amount of cat head stamps it costs 99 cents more. This app needs at least three times the number of cats to make it worthwhile. Don’t buy.

It needs at least three times the number of cats to make it worthwhile!

So, while we’re on a tangent anyway, I’ll indulge myself in posting this picture of the setting I was lucky enough to read this Yahoo article in. Vacation is hard.

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.