The value of talking to customers

I spent about 4 hours last week conducting usability tests. No matter how often I do this, it always amazes me how incredibly valuable it is. Every test reveals something new about the product.

As a coincidence just this week I also came across this article talking about how many Product Managers lament that they don’t have time for customer or market research at all.

“I am too busy writing specifications to be able to do the important customer feedback, research, and strategic work.”

I see this all the time in product teams, and while I get it that there are always more specs to write and more bugs to triage, I always say:

What could possibly be more important than knowing you’re building the right product?

All other things being equal, the company who understands their customer the best will win the customer, and the market.

Talk to your customers. If you don’t have customers yet, then find people in the market who match your target segment and talk to them.

For some tips on how to do that, check out this video.

But whatever you do: get out of the building and talk to your customers.

Great PMs don’t work alone

Sometimes there’s a perception of Product Managers that the best ones are product geniuses who always and immediately have the right answers for every product problem: PMs whose product instincts are so sharp they can arrive at the best solution at a moment’s glance; who can look within themselves and find the solution deep down there and pull it out onto a wireframe through a simple act of will.

I suppose there are a few crazy geniuses out there. And I’m certainly not doubting the power and value of instinct built up over years of product experience.

But the whole truth is that being a great Product Manager is less about moments of divine inspiration, and more about work and grind: questioning, discussing and iterating. Hypothesising, experimenting, failing and repeating. Doing the work.

The whole truth is that great PMs don’t work alone. They’re not mad geniuses who are supposed to always have all the answers.

Great PMs are masters of The Process: the process of gathering input and inspiration from myriad places, and synthesising that into a solution. PMs talk to the customers, to the sales team, the finance team, the engineers: they talk to everybody. They know that ideas and inspiration can come from anywhere, and they actively seek out ideas and input from across the business.

But be careful. This is not the same as “gathering requirements” or “translating business objectives into development objectives” (two definitions that often come up in the context of Product Management that I really hate).

This is not about making sure everybody’s input and ideas are squeezed in to the product. It’s about a process of gathering ideas and inspiration from as far and wide as possible (the divergent thinking phase), then boiling that all down into the solution that best solves the problem for the customer (the convergent thinking phase).

Product instinct is less about always knowing what the solution is. It’s much more about knowing which solution, from a list of possible ones, is most likely to work, and which should be tested. It’s about quickly assessing and prioritising a variety of options and making the right call.

So don’t think you always need to have all the answers. Use your team and your network to build your list of options, pick the best one, or combination of best ones, and go.

On copying well: apply with caution

The Exponent podcast this week on the history of messaging apps talked a lot about copying. They referenced a previous piece from Ben called “The Audacity of Copying Well”, where he talked about Snapchat stories, and how this was so obviously and shamelessly copied by Instagram to make Instagram Stories.

They argued that in business, copying what works from the competition is not only inevitable, but it’s what businesses do to survive and thrive.

If your business is based on something that is easily copyable, then you don’t have long-term competitive advantage. Someone will copy you, do it better and then you’ll be dead. Period.

Every basic business strategy class will teach this. So why do we have this moral outrage when it comes to copying in tech?

There should be no moral objection here. All new tech businesses are essentially taking a known product or theme and building on it; expanding it. On the podcast, James argues that the fact that we have so many companies building off each other’s ideas is precisely the reason there is so much innovation in tech right now.

I wrote yesterday about the danger of copying when you don’t know if it’s working. I was thinking more about copying UX patterns or conversion tactics – but the same is really applicable to business models as well. Learn from your competitors. If they have built something that is easy to copy, and that thing can help your product/business succeed, then use it.

But the warning here applies to copying business models as well. By all means learn from business models that are working elsewhere: but apply with caution to your own business and your own market.

Copy with caution.

The danger of copying

It’s normal when building and optimising a product to take a look at how others have solved similar problems in the past. In fact, this is a critical part of the design and product research phase.

But be careful with assumptions like “Company XYZ does it this way, and they know their shit: they wouldn’t do it that way if it didn’t work, so we should do it that way too.”

I’ve heard PMs and designers say things like this all the time, and although it’s tempting to believe when you’re under time pressure to ship, it’s rarely the right decision just to blindly copy the competition or whatever reference model you’re looking at.

The thing is: from the outside looking in, you have no idea why they decided to solve the problem in the way they did. You don’t know the context of their users and their business.

And you don’t have the data. You don’t know if it’s even working.

Maybe that solution isn’t performing at all and the product team hates it, but they haven’t had the resources or time to improve it yet. You just don’t know.

Get inspiration from those who have solved similar problems before you. The product world is full of incredible people that ship innovative solutions every day, and it would be foolish not to learn from that. And yes, there’s no point re-inventing the wheel. But remember that not every wheel fits every vehicle. Implementation and context is everything.

So don’t copy blind. Don’t assume it will work for you directly. Learn from the best; then make your own decision. Then instrument with good analytics, measure and iterate.

Good Speed: 6 ways to build product faster

Product Management Speed

I recently wrote about why Speed is not the same as Velocity.

Speed is just moving fast, whereas velocity is moving fast in the right direction.

Fred Wilson also posted this week on Urgency, and how in his role as a board member and advisor he presses startups to foster a healthy Sense of Urgency in the business. A healthy sense of urgency breeds what I call Good Speed.

Good speed has a positive impact on your velocity and brings you closer to your goals. Bad speed takes you further away from them.

So what is good speed, and how do you create it?

Here are some PM Rules of Good Speed.

1. Prioritisation

Good speed is about good prioritisation.
Prioritisation is all about answering the question: what is the most valuable thing we can do next? What is the next highest leverage option?

In my previous Growth Team I used the I-C-E method (Impact, Confidence, Effort) for helping to quickly prioritise roadmap items:

  1. Impact: how much value we can deliver to the customer?
  2. Confidence: how certain are we that it will deliver the value we expect?
  3. Effort: how much effort will it take to deliver, and what are the opportunity costs (what are we unable to work on in the meantime)?

Always deliver the highest value things first.

2. Focus, focus, focus

As a PM you’re always in a situation where you have multiple ongoing initiatives: open customer requests and bugs, that strategic partnership, the platform refactoring project and other technical debt, not to mention your product backlog of new features and improvements. It can be tempting to work on many different things at once, as it gives the feeling of progress and momentum on everything. Unfortunately, this is usually a false economy. The more plates you have spinning at once, the more often the team will be context switching between topics, and each thing you’re doing will end up taking longer.

Great prioritisation is all about the things you don’t do.

3. Finishing, not starting

There are always new requirements coming in from all sides. You’ll often feel pressure from stakeholders or customers to stop working on what you’re doing to “squeeze in this important requirement” or “respond to this change”. But if you’re halfway through something, it’s a good idea to finish it first before moving on to the next thing. Putting a task down, and then picking it up a couple of weeks or months later is a big waste of time. You’ll all spend time getting your heads back into the topic, finding the specs and designs, figuring out where you left it, which branch it’s on, etc. The half-written code will be stale, will need to be re-based or maybe even re-written. In the worst case you’ll have to throw away everything you worked on and start from scratch.

Resist the urge to change priorities mid-way through delivering value, as it makes everything more expensive in the long run. Even if it feels like the right tradeoff in that one moment, do the exercise of adding up all the times you do that over a year, and the impact that all those times added up will have on the total value delivered…

3a. Reversal: Beware the sunk costs fallacy

The reversal to this rule applies when you learn something that renders what you are working on right now obsolete. Maybe the company strategy changed, or you obtained new market data. Whatever the cause, if you learn the thing you’re working on is of low value, pull the plug early. It can be tempting to think “… but we’re already half done, we might as well finish it…”. Don’t. The time you’ve already spent is already spent. It’s sunk cost – you can’t get it back. So if the time you spend finishing it could be spent on delivering value that will positively impact your business – then absolutely do that instead.

4. Time to value

Time to value is about how you structure your roadmap and break down features to get to the core value as quickly as possible.

Focus on what is needed to deliver the core value to the customer, and on building that. If what you’re doing is peripheral to the core customer value, consider doing it later, or not at all.

5. Tradeoffs

Fast is often also about making tradeoffs.
The classic: “Let’s skimp a bit on quality now to get the feature out the door, and we’ll fix the bugs later.” Every product team has limited runway ahead of them, but the life-or-death feeling is particularly acute in a tech startup. The pressure from the market to get to value as quickly as possible is real. But make no mistake: skimping on quality is taking on debt. You’ll need to pay it back eventually. Understand this; and make the decision to take on debt consciously, and as a team.

Related: this fantastic article on classic over-engineering mistakes software teams make.

6. Motivation and energy

A high level of motivation and energy will make the difference when it comes to that last 2% that takes you over the finish line. It makes all the difference between “I have to get this done before I go home tonight” and “I’ll take care of that tomorrow.”.

Remember: you cannot mandate motivation, but you can provide the mission and the environment that breeds it.

Good speed is a positive Sense of Urgency.
Get focussed and get finished.

How great Product Managers look forward

There is a lot of day-to-day grind as a PM. Tickets to write, bugs to triage, meetings to facilitate. Maybe the QA team needs help. Maybe the marketing manager is sick and you need to help run an acquisition campaign. There is always something urgent that needs your attention, your time and your focus.

Indeed, good PMs do whatever needs to be done to get the product shipped.

Great PMs, however, never live exclusively in the day-to-day. Great PMs are always looking forward; always asking: “What’s next?”

Great PMs can simultaneously live in the present (this week/next week), the mid-term future (next month) and the long-term future (next quarter/next year). Great PMs can move gracefully through the temporal roadmap multiple times per week.

We live in the present, but we can only intelligently choose what to focus on today by thinking about it in terms of the future: where are we going, what are we trying to achieve, what’s coming next.

Great product teams don’t get stuck iterating the current product forever: the future always comes quicker than we think.

So how do you know if you’re not spending enough time thinking about the future? How much is too much?

When thinking about this for Product, I like to think of the Three Horizon Model.

Three Horizons Model

I first came across this model in the Pragmatic Marketing course. The model was originally designed as a sort of counterpart to the BCG Matrix Model to describe how businesses should invest in product lines over time – making sure to avoid future disruption by investing in future businesses. But I find the model works well at lower abstraction levels, as an abstract way to think about how to invest product time across the three time horizons.

Here’s how it works: For given product, you’ll probably spend around 25% maintaining your current product version. This is Horizon One. This is the product you have in the market right now. This 25% of time might be spent on maintaining your production services, implementing bug fixes, reducing your technical debt or on customer support.

Horizon Two is about the next big thing. A good team should be spending around 65% of their time working on the second horizon: the next product. This could be the next major feature, the next market segment or problem that you’re going to solve. This is your investment in the immediate future: what’s coming next.

Finally at least 10% of your time you should be thinking about the longer-term future: Horizon Three. What is the next market segment you plan to enter? What new technology might change the way you do business or build your product? What environmental changes do you need to prepare for?

The great thing about this model is that you can apply it to any role within a team and it makes sense: for PMs, for QA, for engineers. You an also apply it to any level of the business: at the relatively low level of the product backlog, or to the product strategy, or to the business itself.

The future always comes around quicker than you think, and you don’t want to be caught unprepared. Get done what needs to get done, but don’t get stuck in the present. Remember to invest in the future.

Why Speed is not the same as Velocity

Speed is distance over time. Velocity is displacement over time.

There is a big difference between speed and velocity.

Good speed increases velocity.
Bad speed decreases velocity.

Remember first year physics?
Speed is a measure of distance over time.
Velocity is a measure of displacement over time. Velocity is a vector: it has direction.

Formulas for speed and velocity.

We all know the sensation of running really fast (having high speed) but not making much progress toward our goals (having low velocity).

The red queen has a lot of speed (she is running as fast as she can) but she never leaves the spot she is standing on: the chess board is moving just as fast as she is, and her displacement is zero: so her effective velocity is zero.

The winner of the Berlin marathon ran the course in slightly over 2 hours: an average speed of about 20 km/h. But he finished exactly where he started: all that running to end up back at the same spot. His velocity, after two hours, was zero.

On projects and teams, velocity matters a lot. Velocity is the measure of how much progress you are making towards your objective, your end goal. No matter how fast you’re moving, if your velocity is low, your progress will be slow.

Scrum teams often have a measure of progress called velocity that measures how many user stories were delivered in a given sprint.
Velocity defined as stories delivered over time.

But what if those user stories didn’t add any value for the customer?

Stories delivered over time is a measure of speed. I better measure for velocity is:
Velocity defined as customer value delivered over time.

Increasing speed can increase velocity. But it can just as easily decrease it.

Good speed is efficiency, focus, and delivering the things that your customers care about and that make a difference for your business.

Good speed is asking: how can I make this two-day task into two one-day tasks?

Bad speed is rushing, burning out and piling on technical debt. It’s building features that nobody uses, that your customers don’t care about and that don’t add value to your business. It’s prioritising business needs over customer needs. It’s waste.

Bad speed is asking: how can I make this two-day task take one day?

When you find yourself rushing to speed up, ask yourself: is this good speed, or bad speed?

What would you say… you do here?

I interviewed a candidate for a Product Manager position the other day. I like to ask a really simple question at the start of a PM interview: “What is your main responsibility as a Product Manager?”

The answer I got from this candidate was one that I’ve heard many times before:

“My primary responsibility as a PM is to translate business needs into technical requirements”.

This is a terrible answer. Translating requirements from one language to another is not your job. That reminds me of this:

As a PM, your job isn’t to understand and translate requirements. It’s to understand customer needs. What problems does the customer have, and what product can you build to solve those problems significantly better than how they are being solved today?

Collecting requirements from everyone and boiling them down to the lowest common denominator is not your job. Your job is an act of understanding and creation: understanding your customer’s problems, and creating a solution that is so much better than their current solution that they are willing to pay you (with money or their attention) to use it.

How to build a basic Growth Model

I recently wrote a guest post for the guys at the Mobile Growth Stack. Check it out here.

It covers the basic rules of setting up a Growth Model and what to avoid, and you can download a sample .xls that includes everything in the article.

Head over to the Mobile Growth Stack to check it out. If you use the model effectively, I’d love to hear about it!

An Excel spreadsheet showing a Growth Model and MAU numbers

Product Managers – Learn from Elon Musk: write down your product strategy in prose

desk and writing implements

Last week, Elon Musk posted his second ‘Master Plan’ for Tesla. In it, he lays out the strategy for Tesla for the next decade or so, in a clear, concise and highly readable way. He doesn’t use slides. He doesn’t use visuals or charts or graphs. Just words.

As a Product Manager, when was the last time you put your product vision and strategy into words? Into just words?

I’ve seen lots of product visions presented with powerpoint slides. Decks containing reams of slides with graphs and charts and bullet points. I’ve seen prototypes and visual concepts of futuristic products. But rarely do I see a product vision boiled down into its basic elements and presented in the form of written prose.

Don’t get me wrong: powerpoint and visual concepts are fantastic tools for communicating certain types of things. But the written word, in particular well-written prose, has an efficiency, elegance and clarity that you can’t replace with 80 slides.

If you don’t already, get into the habit of capturing your overall product vision and strategy in prose. Why? Because the ability to write it down in a clear and concise way is the ultimate test of the clarity of your vision.

It doesn’t have to be complicated. Let’s take a look at Elon’s post, and what we can learn from it:

  • The post is highly readable: it doesn’t use technical language, buzz words or jargon and it adopts a very informal style. A strategy brief doesn’t have to be complicated or written like an academic paper, nor does it have to be filled with management buzz words.
  • It is very clear and concise: you know exactly where he’s going and why.
  • The vision is sufficiently high-level: you can see the long-term end goal he’s going after (the vision), and the big building blocks he will assemble, in what order, to get there (the strategy).
  • It’s relatively short: about 1500 words. A strategy brief doesn’t have to be a novel! In fact, the shorter, the better.
  • He breaks down extremely broad and complex macro-economic and environmental topics (global warming, sustainable energy production, etc) into very simple terms.
  • At the end there’s a 4 bullet-point summary containing just 47 words that sums up the entire thing. A decade-long plan summed up in under 50 words. This is the ultimate test of your vision and strategy: can you describe it clearly in under 50 words?

At Amazon, Jeff Bezos famously introduced a rule forcing his executives to present product and strategy proposals in written prose, in what he called narratives.

A quote from the book The Everything Store: Jeff Bezos and the Age of Amazon:

“PowerPoint is a very imprecise communication mechanism. It is fantastically easy to hide between bullet points. You are never forced to express your thoughts completely.”

Give it a try: take 30 minutes and put your product strategy onto paper. If you like I’ll even read it for you and provide feedback! Send me an email or find me on Twitter.