“You can’t use up creativity. The more you use, the more you have.”

– Maya Angelou

Marc Andreessen on getting up early

A refreshing view from Marc Andreessen to add to the currently trendy canon of quotes and articles on getting up early:

"I'm not going to talk a lot about getting up early or going to bed late or anything else related to the course of a typical day, because everyone's different."

Mind you, strong positions weakly held:

"Personally I think it’s worth whatever effort is involved to go to bed early enough to wake up early enough to have a good solid 45 minutes or an hour for breakfast each morning, if you can pull it off."

I emphatically agree with this. Since becoming a dad, spending quality time in the morning has become so much more important (and it's also become so much easier to get up a bit earlier for some reason, allowing me to take the time to have a proper breakfast).

Marc Andreessen on product/market fit

Four quotes from Marc Andreessen on product/market fit:

"Product quality and market size are completely different."

That is, just because your product is totally awesome, doesn't mean you're going to be really successful. You need there to be enough people who are actually going to buy the product:

"Market is the most important factor in a startup's success or failure."

The market is where the money is made. If there's no market, there's no product. And if there is a market:

"The market needs to be fulfilled and the market will be fulfilled, by the first viable product that comes along."

If there's a market need, then the market will make the product a success. And the product doesn't have to be awesome, it just needs to be viable. Though I doubt it's a problem if the product is awesome. That probably makes things easier. Regardless:

"Do whatever is required to get to product/market fit."

Andreessen recommends aggressively pursuing product/market fit, making sure you're focussed externally on understanding what the market needs, what problems your customers have, and making sure that your product is a viable solution to those problems, packaged in a way that suits the market.

While you're procrastinating, just do lots of other stuff instead.

Marc Andreessen

Established companies vs startups

I've been reading Marc Andreessen's The Pmarca Blog Archives using Read. Read makes it really easy to save highlights — it saves them automatically to Evernote and also sends you a weekly summary by email, so I'm going to do a couple of posts collating a few of the highlights I made. Loads of his articles are specifically about launching startups and getting VC funding (Marc Andreessen is a partner at Andreessen Horowitz, one of the preeminent tech VC firms). I'm not so interested in that stuff. But he also has plenty of interesting and useful thoughts on product management, technology, and business in general.

Let's start with a couple of quotes about the differences between how work gets done in startups and how it gets done in established companies.

"In a startup, absolutely nothing happens unless you make it happen."

"In an established company — no matter how poorly run or demoralized — things happen. They just happen."

I think it's necessary to qualify that: in an established company, things that usually happen, happen. There are some lessons here from startups from those of us established companies. If we're trying to do something new (e.g. change a workflow or implement a new tool), then it's not going to happen unless you make it happen. You're fighting against the inertia of the established company.

Goal time vs tool time

Jared: Yeah, so one of the things we’ve been doing with clients is when we take these video tapes and we actually start dividing up the tape into pieces, and any place where the trainer is in essence helping the customer get value – so, in other words, that particular thing, like the customer setting up their first account or their first class or putting in their first instructor, right? They’re getting value from that, and so we call that "goal time".

But the places where the trainer is sort of explaining – like there was one option that took about – we counted it – it was about six minutes to explain that you should always keep this number set to one. Whatever you do, don't change it, but then went on to explain why it was there and why it might not be one for people who weren't you, but you should always have it as one.

Hagan: Yeah, don’t touch it.

Jared: Exactly. And so we call that "tool time", right? So that’s the time that you have to just sort of deal with the tool. And you can actually measure how good your UI is doing by the ratio of tool time to goal time, right?

— Transcript from an interview with Hagan Rivers about Simplifying Complex Applications on the UIE podcast

I've spent time training on enterprise software and have encountered exactly this time and again. I think this tactic of identifying goal time and tool time is not just useful for measuring and improving the UI, but is great for designing and implementing training strategies. Training plans should be focused on goals (could also call them outcomes), with time spent learning the tool used to support that — as sidenotes or footnotes in documentation, for example.

Relating this back to product management, you can also think about tools as features, and goals as tasks or opportunities ... and you should be focusing your roadmap on those tasks and opportunities — what your users need to actually do, or what problems you're solving for them, not how to do that.

Quality is fractal

A while back I was listening to the Product People podcast, an interview with Des Traynor of Intercom. The whole interview is full of great tidbits about product management (e.g. "I think not talking to your customers was always a pretty pathological thing to do"), but one idea jumped out and stuck: "quality is fractal". The principle here is that if you look at any one piece or aspect of a product or organisation, that piece or aspect is representative of the whole thing. So you can make an intuitive judgement of the quality of a product based on your knowledge of the background and passion of the CEO, or the quality of a podcast based on the attention to detail given to the intro music or adverts.

I really love this holistic perspective to thinking about product. Compare with Peter Merholz's idea that there is no such thing as UX Design ("user experience is an emergent property of an entire organisation, not just one group") and Seth Godin on how everything is marketing (a derivation from David Packard's "marketing is too important to be left to the marketing department").

Software is a waitress

I was talking this week with some folks at a software company who are working on ideas around automating various financial services transactions from end-to-end, seeking to make it possible for the end user to perform the whole transaction without needing to interact with a real person (there are various benefits to this approach including efficiency, reduced cost, and the user's perception of control/ownership of the process).

Now, it's not (yet) possible to replace every aspect of the business process with an automated solution, but this company are trying to make it appear like this has happened - to make it impossible to tell whether you're dealing with a person or a machine at each point. Their strategy is to make the copy they use in their interface informal and chatty, and this reminded me of another old article I had sitting around waiting to be blogged, which talks about how software is a conversation:

While depending on the brand of the software experience the voice of a piece of software can vary to a certain degree, the baseline to start with is that of someone friendly, but not overly familiar, and ultimately there to serve – an incredible server at your favorite restaurant perhaps? There when you need them, gone when you don’t. Not overly familiar, but definitely putting you at ease. Efficient in language — definitely not verbose. And ultimately focused on serving the user effectively without being overly familiar or chummy.

I think this is a great guideline to use. Overly familiar language can come across as tacky or gimmicky, though it's possible to carry it off with the right brand - Mailchimp do it really well, for example - but that doesn't mean that software can't be personable, and certainly doesn't mean it has to talk like a machine.

Focus on customers and tasks, not features

Gerry McGovern writes about customer-centric approaches to web content, specifically agitating for a relentless focus on the top tasks of a website's customers. I've had this snippet from an article of his about Yahoo, a content company, hiring Marissa Mayer, a product person, as CEO sitting around since mid-2012, and my recent post about features and product roadmaps inspired me to finally do something with it.

I never advise clients to focus on the content. A content focus generally leads to dead ends and a whole raft of bad practice. Focus on the customer instead and what they want to do.

The difference in approach and thinking may seem subtle and academic but it is critical to success. Content thinking and technology thinking are classic organization-centric approaches. People don't want to get to the 'book a flight' tool. They want to get to Dublin from London. People don't want the installation manual. They want to install the product. For most people, content or technology is not the end, not the point.

For content, read features. Focus on customers and tasks, not features.

Feature requests, product roadmaps, and the opportunity backlog

Recently, I took part in a short chat on the Product Manager HQ Slack group about idea management and best practice for logging feature requests. I was reminded about the Forget Feature Requests chapter in Getting Real by 37signals:

"Don't worry about tracking and saving each request that comes in. Let your customers be your memory. If it's really worth remembering, they'll remind you until you can't forget."

Marty Cagan has also campaigned against maintaining lists of feature requests:

"First and foremost, your job is not to prioritize and document feature requests. Your job is to deliver a product that is valuable, usable and feasible. The feature request spreadsheet works against this end by pushing through features that users don't value or need, increasing complexity, decreasing usability, and wasting engineering cycles."

He's talking there specifically about the danger of letting your product roadmap be formed from feature requests. He expands on that by pointing out that the product manager should be focusing on the holistic view - i.e. the vision/strategy/context of the product - and that putting the detail of specific features on the roadmap distracts from that, given that the proposed feature may not actually be the best way to meet the goal of the user.

The other general problem with building product roadmaps from features is that until you've built the feature, you don't know how long it's going to take. And there's a strong expectation on product roadmaps - from sales, from support, from customers - that the roadmap will give some indication of schedule.

Cagan doesn't write off product roadmaps. In fact, he comments that they're one of his favourite tools, as long as they are used to explicitly describe the path from where you are now to how you're going to reach the vision of the product strategy. They should be simple, high-level, and based around objectives, not features (the folks at ProdPad use similar principles, with a roadmap built around goals and projects rather than specific features, and with strategic initiatives/themes colouring each item on the roadmap).

The opportunity backlog

So the product roadmap should simply and clearly define how we'll achieve our product vision over time at a high level. But how does the actual work get managed, defined, and prioritised? Typically there'll be a low level queue of work to be done, usually called something like the product backlog (which should be a prioritised set of user stories or similar). And usually the product backlog is created from the product roadmap. But there's a problem here, as Cagan says:

"Most people assume that when something goes on the product roadmap, that the team has every intention of building and launching this. The problem is that if the product discovery team is ... validating the ideas with real customers and users as well as stakeholders, then they’ll typically find that at least half of what is on the roadmap is simply not worth doing (usually because the customer doesn’t value it as much as we had hoped, but there are several other reasons that we may decide this is not worth building)."

He suggests repositioning the product roadmap as an opportunity backlog, allowing opportunities for the product to be individually assessed to understand the problem that we're trying to solve, who we're trying to solve the problem for, and how we'll know if we've succeeded. Repositioning in this way also creates an advantage over a classic product roadmap in that we're no longer listing specific proposed solutions. This means that if our attempt at solving the problem (our feature or proposed solution) doesn't work, we can come at it from another direction - we're trying to make sure we solve the problem - whereas if we've put specific features on the roadmap, then we have to deliver those specific features (because our customers and other stakeholders expect them and have planned for them), even if they don't actually solve the problem or improve the product.

So, your product roadmap should not be based around features, it should be focused on identifying and prioritising the problems that you're trying to solve.

When we meet new people, we’re tempted to ask: ‘what do you do?’ We’re picking up on the idea that our identity is very linked to our daily tasks… So a dental hygienist will explain how they keep plaque at bay… However, what’s more revealing, but more elusive, are the psychological requirements and consequences of jobs… If we asked: ‘what’s the psychological character of your work?’ the answers would look very different. The dental hygienist might say: I deal a lot with evasion and weakness of the will; otherwise intelligent, trustworthy people cancel on me all the time, blaming their schedules. When they do show up, they sit in my chair and repeatedly lie to me about how much they’ve flossed and break all their promises they made last time about looking after their teeth. I’m daily brought up against how hard adults find it to do pretty basic things that are in their own interests. It can make me a bit stern.’

How Your Job Shapes Your Identity, at The Book Of Life.

Whilst the general thrust of this essay is around the subject of how the work we do defines and alters who we are and how we behave, at a psychological level, I found some of the discussion and ideas interesting from a product management and requirements analysis point of view.

At one level, in trying to design effective products, we need to understand not just what people are trying to do, but why - what are their reasons and motivations for doing the work? What are the skills, capabilities, and constraints that are going to affect them in doing the work? This differentiation is sometimes described in requirements analysis as functional goals and non-functional goals. Satisfying a user’s non-functional goals is a critical aspect of the success of a product, often overlooked.

The essay also provides an interesting technique - seeking to categorise jobs according to psychological profiles, it suggests that jobs can be analysed against spectrums of various traits:

Patience (aeronautical engineer) vs impatience (news editor)

Suspicious (antiques dealer) vs trusting (air traffic control)

Speculative (think tank researcher) vs concrete (fresh fruit logistics)

Consensus-seeking (school teacher) vs independent (tennis coach)

Optimistic (sommelier) vs pessimistic (accountant)

Financially focused (corporate executive) vs sheltered from finance (academic)

Dignity is fragile (poet) vs a solid status (vet)

Better nature (midwife) vs worse nature (police officer)

Logical hierarchy (airline pilot) vs haphazard hierarchy (politics)

Declining industry (publishing) vs growing industry (social media)

It’s so important to understand who your users and customers are. A product solving the same problem for each of those jobs (say, knowledge management) should be designed totally differently for each context.

Many of our job designs, work flows, control mechanisms, and organizational structures came of age in a different competitive environment and before the advent of the computer. They are geared toward efficiency and control. Yet the watchwords of the new decade are innovation and speed, service and quality.

Reengineering Work: Don’t Automate, Obliterate. So true. This is from the Harvard Business Review…in 1990. That new decade is the 90s. Things change slowly, even in tech.

“Technology is no longer an industry category. As has been well-chronicled, it has become a foundation to every business, ranging from healthcare to transportation to finance to education and beyond. Every company will be a technology company.”

From #Angels, on Medium.

Technology is no longer an end in itself. Every company will have to embrace technology, and that means that those of us working in technology have to keep getting better at making it easy to use, effective, and transformative, adding to the top line not taking a cost out of the bottom line.

Slate's Working

I think that one of the most important things that product managers can and should do is to really understand how their customers get their work done. I also believe that product managers should always be seeking to explore their problem space and try to create innovations that change and improve the way their customers work, in ways their customers have never considered. A great way to do this is to learn from adjacent or even unrelated domains. In creative thinking, this is learning from analogy, cross-pollinating from outside the problem space.

On my commute recently, I’ve started listening to podcasts. I’d never got into podcasts, but since becoming a father my reading time has been eroded and it turns out podcasts whilst commuting are a terrific proxy. I’ve been listening to a few product management podcasts - e.g. This is Product Management from Alpha UX, highly recommended - but the one I’m going to focus on is Slate’s Working.

Slate’s Working takes a simple premise - interviewing people in various jobs about they go about their work - and turns into something fascinating. On one level, it’s an excellent primer in how to interview customers to help them voice their business drivers and goals, but I’ve been really interested in how even the mundane aspects of work can be thought-provoking when you observe them in unfamiliar situations. This is a great show.

Invoice early and invoice often.

Sensible business tip, from Louis Rosenfeld.

That architecture is all the stuff I spent ten years ranting on this blog about, but y’all don’t listen, so I’m just going to have to build company after company that runs my own wacky operating system, and eventually you’ll catch on. It’s OK to put people first. You don’t have to be a psychopath or work people to death or create heaps of messy code or work in noisy open offices.

Joel Spolsky, Trello, inc. (Have you tried Trello yet? Trello is great. Try it.)

Let's wake up at 4:30am...no, 3:30am...no, wait...

So I read this article on Medium about 12 Lessons of Waking Up at 4:30 a.m. for 21 Days:

And I thought so that seems kind of cute, more power to him. And then I got to the end and Medium recommended some further reading:

So I think maybe we should get up at 2:30 a.m.