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.

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.