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.

Early Growth: Look for “Pockets of Demand”

In the early days of launching a new product, it’s useful to think about your market in terms of “pockets of demand”.

A pocket of demand is of course another way of saying “target market”. It is essentially identifying a group, or niche, of potential customers who share a common problem that you can solve extremely well: people for whom your product is the greatest thing in the world.

The advantage of thinking in terms of a “pocket of demand” is that it encourages you to focus on that pocket, that core market, even when this is potentially to the detriment of the broader market.

But why is this a good thing? Because when you are trying to nail product market fit, thinking too much about the broader and adjacent markets can often lead to a tendency to want to solve too many problems at once. No market is completely homogenous, and you might start making too many compromises instead of focussing on what’s truly important for your core target market.

Knowing your pocket of demand can also help you optimise your go-to-market strategy to find exactly these customers, which can help lower your customer acquisition cost.

In Peter Thiel’s book Zero to One, Thiel talks about the early days of Paypal. Their first target segment – their initial pocket of demand – was Ebay “PowerSellers”. From the book:

“We set our sights on eBay auctions, where we found our first success. In late 1999, eBay had a few thousand “PowerSellers”, and after only three months of dedicated effort, we were serving 25% of them. It was much easier to reach a few thousand people who really needed our product than to try to compete for the attention of millions of scattered individuals.”

They zeroed in on the needs of that niche, and solved their problem – safe, cheap and fast online money transfers – and only after they had nailed that did they expand the value proposition to include broader slices of the market.

When it comes to growing your customer segment, you have two choices:

  1. Try to expand the penetration of your product within the pocket of demand you’ve identified, or
  2. Expand the offer to adjacent pockets of demand.

When Amazon started out, Jeff Bezos had a vision: to build the “Everything Store” – an online store far bigger, stocking more items, than any physical retail store ever could. But the first years of the company focused on a specific pocket of demand: readers. They spent a couple of years expanding their selection of books before expanding into other retail categories.

What is the pocket of demand that you are addressing?

User Experience is everybody’s job

I’ve met lots of product teams who will tell you: “User Experience is a design thing.” They hire ‘User Experience Designers’ to design the User Experience, and generally assume that they alone are responsible for the overall UX.

I believe that simply assuming the User Experience is a ‘Design Thing’ is a very dangerous mindset, for three very important reasons.

UX is in the middle between Product, Design and Technology

Within a product, the overall User Experience isn’t delivered only through design.

Certainly a big part of the UX is the visual design, the interaction design, the brand design, and so on. But an equal part of UX is the implementation of that design through technology. The danger in assuming that UX is a ‘Design Thing’ is that it quickly leads to people from other disciplines disconnecting from worrying about the User Experience at all. Every technology decision has an impact on the User Experience, which makes every engineer who is making any technology decisions – (which is every engineer) – equally responsible for ensuring a great UX.

Too often I see product tradeoffs being made where teams decide to sacrifice the user experience in favour of saving time, saving cost, avoiding that refactor or simplifying that internal process. These are all terrible reasons to sacrifice the User Experience. Additionally, sometimes the best User Experience improvements come exclusively through technology improvements. For example performance improvements, which can have a huge impact on UX, often come from deep and complicated engineering innovation.

Engineers: The User Experience is your job, too!

User Experience is also about solving the right problems for the user, and solving them with the right priority.

The user will judge the user experience to the extent that it solves their problem. A perfectly executed product that doesn’t solve a problem for the user won’t lead to a great User Experience.

This is where Product Managers should feel in command of the User Experience: in making sure the problems you’re solving are urgent and pervasive within your market segment, and that the solutions you are delivering are differentiated and defensible. Make no mistake: this has the biggest impact on your User Experience – and the resulting product success – than anything else, so it makes sense that you should focus here.

Product Managers: The User Experience is your job, too!

The overall User Experience goes beyond just the app/website/service/widget that you’re building.

When we’re working as Product Managers on digital products, we’re all so concentrated on our app, website, widget or whatever, that it’s easy to lose sight of the fact that your app is just one piece of the whole User Experience.

The overall UX starts the moment the user first hears about your product, and goes all the way to support, fulfilment, billing, etc. In other words, the User Experience spans the entire customer lifecycle.

We hire people with titles like ‘User Experience Designer’, but then put them to work designing user flows within single apps or products. To me, there is a difference between Interaction Design and User Experience design.

Interaction Design is concerned with the design of discreet experiences – interactions – within customer experiences. How does the user interact with this feature/product/widget?
User Experience Design takes a holistic view of the entire end-to-end user journey – from their first contact with the product via a marketing message, the app store or even a word-of-mouth recommendation, all the way to customer support, billing, delivery, etc.

But it’s not only the job of the User Experience Designer to think end-to-end. Everybody working on the product should have the entire end-to-end flow in mind, to understand the unique context of each user, why they are there, what problems they have and what they are hoping to achieve.

Marketeers, Support Engineers, PR folks, Delivery technicians, Logistics technicians, etc: The User Experience is your job, too!

Why this matters

Users have more ability to discover and switch to new services than ever before. Traditional lock-in effects like platform dependencies and data ownership are eroding thanks to open platforms and data portability, and there are great alternatives in every product vertical. The thing that keeps people using your product or service is the quality of the user experience, from end to end.

Companies that become great and enjoy great customer loyalty do so by developing a culture of unwavering customer focus. Sure, many companies say they are customer focussed, but actually being customer focussed is more than just a mission statement – it’s a deeply embedded culture that everyone lives and breathes from the CEO down.

A couple of examples:

  • Facebook prioritises the customer experience over everything. Facebook understands that their business model depends on gaining more and more users who each spend more and more time using Facebook. Their business is cultivating user attention. Everything else in the business comes second to user engagement.
  • Amazon is another company which was founded and grew on the fundamental premise of making the experience great for the customer. When Jeff Bezos launched Amazon.com in the mid 90s, he knew that the key to scaling massive consumer adoption extremely quickly was an unwavering focus on a great customer experience, and he considered the customer the most important thing in the business. He built this customer-first attitude into the company’s DNA from day one, and every innovation they have delivered – from 1-Click ordering, to personal recommendations, to the Kindle eReader to the voice-controlled Echo – has been about making a great customer experience and making it easier to shop and interact with your content.

A few ways to make sure you’re thinking end-to-end about UX

  • Do you share a common set of User Personas across all departments, including tech, QA, product, design, marketing, comms and support? Having a common set of personas ensures that everyone has the same user in mind when designing their solutions.
  • Does your QA team test the entire acquisition and on-boarding funnel? It’s important, but insufficient, to focus your QA efforts on the app/website/etc. You need test coverage of the whole end-to-end experience. If you don’t QA your marketing or your support functions, you should consider doing so. For example, you can test your support team with the ‘secret shopper’ approach.
  • Consider a ‘Stop the line’ policy for the User Experience. It’s a familiar concept to your engineers – certain situations within the build environment, such as test coverage dipping below a certain level, or open bugs exceeding a certain threshold, will trigger a ‘stop the line’ where no new check-ins can occur until the situation is resolved. What if you did the same for User Experience? What if you gave everybody in the product team – from Product Management and Design, to Engineering, QA, Marketing, Comms, Support, etc – the permission to Stop the line? To put a pause on building anything new until the UX issue is resolved? What impact would that have on your customer focus?

Ultimately, the User Experience is the culmination of every touchpoint you have with your customers. This experience can, and should, be designed from end to end. But it’s not just the ‘job’ of Design to get it right.

UX is everybody’s job.

Growth Product Managers: You should learn to code Python. Here’s why:

Python code

<tl/dr>

Growth Product Managers and Growth ‘Hackers’ should learn to code Python: it saves time by automating reporting and analysis, and it will make you a little less dependent on your data science team and a little more confident to go looking through your analytics data yourself.

I run Growth and Monetisation for HERE’s consumer app business. We have an Android and iOS app, a mobile web app and a desktop web product. We are collecting a ton of app usage and attribution analytics, but they are spread out across multiple places: mobile attributions in Adjust, mobile analytics in Amplitude, web analytics in SiteCatalyst, and so on.

The dashboards provided by the analytics tools are great, but I found myself logging into multiple web dashboards every morning, exporting CSV files and importing them into an excel file to get just the view of the data that I wanted. I was spending 30 minutes per day just cutting and moving data around to get the view I wanted, and I decided there must be a way to automate it.

There are a few options when it comes to scripting languages to let you easily pull and manipulate data sets. Your data science team probably uses R, but for Growth PMs a great place to start is Python. Python is a general-purpose interpreted scripting language that is both extremely versatile and easy to learn. It is inherently great at working with data sets, but there are also a ton of additional libraries available designed especially for data science that make fetching and analysing large data sets, like your app analytics, really easy.

Here are a handful of things you can build yourself with a bit of Python scripting knowledge:

  • Automate checking your dashboards and compiling data in the way you want to see it.
  • Save time manually exporting CSV files from different sources and creating an Excel file to see the data how you want to see it: use python to pull all the data sources automatically and crunch them into the right format.
  • Perform basic analysis automatically at regular intervals and email yourself and your team the results.
  • Create an automated ‘early warning’ system: if any of your key metrics start changing (going up or down) at a certain rate, create an alert email. This is a script that could run automatically a few times per day to monitor key stats and email you and your team when any key metric starts changing drastically.

Example
As an example, I uploaded one of my basic scripts to GitHub. Take a look here.
This basic script does a couple of things:

  • Allows you to specify a couple of frame variables at the top for how you want the data returned: you can specify the period, the channel grouping, and choose between active or new users.
  • Pulls app analytics data from Amplitude for an Android and iOS app sequentially.
  • Adds two columns to the end, one for the standard deviation and one for the % change between the last two complete periods.
  • The script prints out the channels that have gone up or down by more than 2%. (This variable is configurable at the top of the script as well, allowing you to adjust the sensitivity).
  • For data that is grouped by Country, it will also print the % change for a list of pre-defined ‘Key Markets’.

This is just one simple example for one particular analysis – but you could write a script to pull and combine data in any way you choose, depending on the analysis you want to perform/automate.
(This post is not intended as a ‘how-to’, but if you want help, you can contact me. Also there are some resources for getting started with Python at the bottom of this post.)

The best Growth PMs live and breathe their data. Learning to manipulate and analyse your product’s data with Python will save you time by allowing you to automate many reporting and analysis tasks. The act of working with your data at a raw level will also help you fully understand it.

Your data science team are of course the experts, and you’re not likely to become more competent in programmatic data science than they are – but you can learn enough to make yourself just self-sufficient enough to be able to answer your most burning questions immediately, and you don’t rely only on your data scientists and analysts to create the reports and dashboards you need.

Resources and getting started
There are a ton of great resources out there to help you learn Python. Some assume previous programming experience, and others are designed for absolute beginners. It really doesn’t matter if you’ve never programmed before (although, of course, it certainly helps). If you have a good understanding of data manipulation in Excel, for example, you should be able to pick up data analysis with Python with a bit of patience and practice.

Some resources to get you started:

  • datacamp.com is a great place to learn the basics of Python for Data Science. The basic python course is free, and $25 will get you access to the intermediate course, which covers the most important things you’ll need when using Python for data analysis.
  • A more general Python beginners course is available at codecademy.com.
  • The O’Reilly books are relatively expensive, but they’re the classics.
  • Of course, stackoverflow.com is a gold mine for budding and advanced programmers.

Note
Although I studied Computer Engineering I don’t consider myself a programmer. My scripts focus on simplicity and getting the job done, and in so doing break occasional rules and programming best practices (I use global variables a lot, my conventions are sloppy, etc). But that doesn’t matter. As Growth PMs, we’re not contributing to a large codebase with lots of other developers: we’re programming just for us. So don’t get caught up in conventions, unless they help you write code that you can understand.

The Complete Product Manager

Being a great Product Manager in tech is more than shuffling roadmaps and writing user stories.

Great PMs are first and foremost masters of their market: the segments, the customers, and their needs, and they spend a great deal of time talking to customers themselves and conducting field research.

Great PMs are the walking embodiment of their product and their vision. Great PMs want to build great things, and naturally inspire people to join them.

Great PMs understand how their product idea will become a product business, and they understand what needs to get done to get there.

Great PMs know and respect their competition, but they are not intimidated and focus on solving users’ problems better rather than comparing feature lists.

Great PMs are masters of their domain of business and are thought leaders of their industry.

Great PMs are driven by intuition, but formulate hypotheses and test them using rigorous analytical methodology.

Great PMs understand how technology can help solve customer problems in new and delightful ways.

Great PMs have a natural sense for design and focus relentlessly on the end-to-end User Experience.

Great PMs have a growth mindset, and build a platform for systematic growth for their products from day one.

Great PMs are natural born leaders. They inspire and motivate, rather than dictate.

Great PMs are passionate, resourceful and curious. Great PMs are relentless in the pursuit of a better product.

 

 
The Complete Product Owner

 

 

Amazon Kindle and the Perfect Product Vision

In the recent fantastic piece on The Verge covering interviews with the top brass behind the Amazon Kindle, the ultimate product vision behind the Kindle series of eReaders is articulated beautifully. From the article:

For Amazon, paper is more than a material for making prototypes. It’s the inspiration for the Kindle of the future: a weightless object that lasts more or less forever and is readable in any light. “Paper is the gold standard,” Green says. “We’re striving to hit that. And we’re taking legitimate steps year over year to get there.”

The beauty of this is its simplicity. Amazon are striving to create electronic paper. “Paper is the gold standard. We’re striving to hit that.”

There is nothing here about the joy of reading, or empowering people through instant delivery of information, or making money. The beauty of this is that all of those things flow naturally from the core premise: to make better, electronic paper.

This is what the Kindle team says about itself. It’s clear, it’s inspiring – and it’s impossible to misunderstand.

Compare that with this:

“Reach the largest daily audience in the world by connecting everyone to their world via our information sharing and distribution platform products and be one of the top revenue generating Internet companies in the world.”

That mouthful appeared on a slide at Twitter’s first analyst day. Inspiring? Do you even understand what the hell its trying to say? It could mean anything and everything – and that’s the problem.

Imagine your first day on the job at Amazon in the Kindle division. You ask, “So what is our mission? What are we trying to do?” In answer, someone might hand you a piece of paper, and tell you: “We want to make that.”

A good product vision is inspiring and motivating; an irresistible imagined future that pulls you towards it like gravity. But a good vision is also impossible to misunderstand. Everybody should share the same view, and be pulled in the same direction.

Product Manager in the middle

The Product Manager isn’t just a middle-man.

If you’re a PM, and your answer to every question is: “I don’t know, I need to go and ask ___”, then I’m afraid you’re doing something wrong.

You might not be able to give engineering estimates, but you should know your team and your technology well enough to give an educated guess; even if you have to follow up by saying “I’ll double-check that with engineering and get back to you.”

You might not have a slide prepared on every possible strategy question, but you should be able to form an opinion immediately if somebody throws you a strategy curve-ball.

You might not have the answer – but you should at least have an opinion.

Good Product Managers don’t wait to be told what to do by stakeholders. They anticipate stakeholder needs and suggest new ideas.

Good Product Managers don’t push decision-making up to senior management. They take responsibility, and if anything push decision-making down. Either way, they stand accountable for the decision and own up to it.

Good Product Managers never say “I don’t agree with this decision, but…”. Even if they think it.

No company needs more middle-men.

Companies need passion, vision and conviction. Grit.