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?

Notes on using the iPad Pro for “real work”

The iPad Pro is a capable machine for getting all kinds of “real work” done while on the go.

After much deliberation, I bought myself a new iPad Pro 9.7″ about four weeks ago, and since then I’ve been running an experiment to see if I could use my iPad for “real work”. Inspired somewhat by Steven Sinofsky’s treatise on why his iPad Pro has stickers, I wanted to see if I could leave my MacBook at my desk all the time, and only take my iPad with me when I’m on the move (in meetings, working remotely, etc).

My MacBook has been chained to my desk for three weeks now, and since then I’ve written blog posts (like this one), worked on spreadsheets, taken handwritten notes, read and responded to email, set up meetings and managed my calendar, presented with slides at meetings and taken notes, joined video conferences, made drawings, including a few lessons from a “learn to draw” course, surfed the web, read and marked up eBooks, written Python code, played games, watched Netflix, Amazon Prime Video and the European Championship, booked flights, ordered groceries, bought clothes on Zalando and bought other stuff on Amazon: all from my iPad. It is truly the most versatile computing device I have ever used.

The iPad is a capable machine for doing "Real Work" on the go.

The iPad is a capable machine for doing “Real Work” on the go.

In many ways, all of the things you wanted to do with your first iPad, but couldn’t, are now possible. The hardware is faster, lighter and better, for sure, but the biggest improvement is the software, both iOS and third party apps. Thanks to iOS extensions and multi-tasking, apps work together better than they ever did before. Persistent cloud services are baked into everything, so data and preferences are immediately synchronised across all your devices and available everywhere. Microsoft’s Office suite is now thoughtfully designed for iOS and they plug into OneDrive perfectly, and meanwhile Dropbox, which I use for personal files, is integrated into all other apps that I use so I can get files in and out of other apps easily.

I had an iPad 1 when they first came out in 2010, and I bought an iPad Mini Retina a few years ago. Neither of these devices found a way into my regular work routine. Neither was in any way capable of replacing my MacBook for anything other than web browsing, and with an iPhone in my pocket there was little upside to offset the added weight and hassle of carrying the thing around, so I couldn’t find a way to build them into my workflow in a meaningful way. There were too many reasons doing Task X on my MacBook or Task Y on my iPhone was just easier. The iPad 1 was quickly relegated to the coffee table by the couch for occasional web surfing, and nothing else, and my daughter appropriated the iPad Mini as a Netflix device. Now, however, with the iPad Pro I can safely leave my MacBook on my desk for the most part, and use the iPad in all the scenarios when I want to be mobile.

There are plenty of ‘real work’ tasks that I could easily get done on the iPad Pro while away from my desk. Here are some observations:

  • Reviewing a document or set of PowerPoint slides by scribbling on it directly with the Pencil is lovely: it’s so much quicker and more intuitive than typing everything with comments: you can quickly highlight stuff, draw arrows to indicate changes, and add quick comments in the margins. But if you want to edit a longer passage, the keyboard is right there when you need it. (One of the guys in my team told me he’s had term papers come back cleaner. 😉)
  • With a HDMI dongle, presenting with the iPad is easy – and it’s even easier when you’re presenting to a TV with Apple TV/AirPlay.
  • No fussy display settings to worry about: mirroring worked first time, every time for me.
  • The PowerPoint app does a great job of presenting. You can add mark-up to your slides in real time with the pencil (that are automatically discarded when you close the presentation), and it also has a little ‘laser pointer’ feature, where you can point to something by holding on the slide preview.
  • It’s a bit harder to take notes while presenting, though, because the iPad won’t let you have a different app running on the device while presenting, but you can take notes either as annotations directly on the slide, or in the slide ‘notes’ field.
  • Excel works just fine, and you can view complicated sheets and update them easily. I must admit I miss my large dual-monitor setup for working with large and complicated sheets, but I was surprised how capable the iPad version of Excel is.
  • Long-form typing is easy when you attach a Bluetooth keyboard. I’m using the Bluetooth keyboard from my MacBook, and it works just fine.
  • Using the Apple Pencil to take handwritten notes is also great. I used to carry around a slightly larger than A5 Moleskine notebook for taking notes, scribbling drawings, etc, and I would scan in the important ones to Evernote. The iPad and Pencil combination has completely replaced that for me, with my handwritten notes going straight into Evernote, which saves me an extra step of scanning, and saves me carrying around an extra heavy notebook and pens.
  • Having all your files in the cloud makes working life on the iPad possible. I always have access to everything I need, without having to think about it.
  • I’m using Outlook for email, and the way PowerPoint and Excel are built in make it simple and seamless to open documents, review them, and quickly send back your comments.
  • All the apps I use in my normal workflow on the Mac are available and optimised for iPad: Outlook, PowerPoint, Excel, Evernote, Wunderlist, Pocket, Dropbox, OneDrive, Skype, Slack and of course Safari. (Sadly however the Twitter app on Mac is even more crappy than it is on iPhone.) I didn’t have to swap to any new apps or re-learn any behaviour. It’s all there, with all my files, context and history.
  • The iPad also works as a great accessory for the MacBook when you’re at your desk. With apps like Duet you can use it as an extended screen, or Astropad can turn it into a Wacom-like tablet. You can quickly scribble down ideas like in a paper notebook and have them appear immediately on your Mac.
The iPad is really versatile - and great for ebooks.

The iPad is really versatile – and great for ebooks.

Where I did miss my MacBook:

  • My dual-monitor setup. There’s no denying that for some work, like working with big excel sheets, illustrations or presentations, the size of a large monitor, and the accuracy of a mouse matters a lot.
  • Split-screen multi-tasking on the iPad is good, but it is definitely not as quick and seamless as on the Mac to work with multiple documents and apps simultaneously. The iPad also lacks completely the ability to view two different documents of the same type next to each other: for example, two PowerPoint documents, two Word documents, etc. It will be great to see Apple open up the multi-tasking to allow single apps to run multiple instances of themselves in different windows.
  • In terms of apps, the only apps I absolutely cannot use on my iPad are Photoshop and Illustrator, which I use quite often for designing screen mock-ups or for building visuals for presentations. There are alternatives designed for the iPad, but I haven’t found one that completely convinces me yet.
  • Some apps don’t support rich text editing, such as the Outlook app, which is a pain. It’s annoying to always have to send emails in plain text.
  • I can’t say that I found using the iPad in “laptop mode” ergonomically superior to using a laptop with a trackpad or mouse. In fact, I found raising my arm and reaching across the keyboard to the screen to touch some screen element with my finger tiring after a while.

You can get an incredible amount of work done on an iPad. If I ever did find myself frustrated that I couldn’t do something on the iPad, most times it turned out that I could do it; I just needed to do it in a different way.

When you spend a few days using the iPad for everything, you come to appreciate how versatile it really is. One minute you’re typing up a report or an email, then you’re reviewing and annotating a document with the Pencil. After that, you might sit back and browse the web, look at your photos, and then open up the Kindle app and continue reading your book – all from the one device. I would argue that no other device has come anywhere this close to being truly one device for everything.

I'm clearly never going to be an artist, but yes, I drew this, and it's quite impressive what even a layman can achieve drawing on the iPad Pro with the Apple Pencil

I’m clearly never going to be an artist, but it’s quite impressive what even a layman can achieve drawing on the iPad Pro with the Apple Pencil

Tim Cook likes to say that the iPad is “the clearest expression of vision of the future of personal computing.”
They’re not there yet… But I can clearly imagine a future where personal computing is truly versatile, portable and intimate, and in my view the iPad Pro is the clearest version of that yet.

Steve Jobs famously said at the launch of the iPad that having a touch screen on a laptop would be "ergonomically terrible".

Steve Jobs famously said at the launch of the iPad that having a touch screen on a laptop would be “ergonomically terrible”.

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 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.

Ways to think about Android Instant Apps, and what it means for developers

This week their annual developer event Google casually announced a huge new feature coming soon to Android: Instant Apps. Chris Maddern called it their “one more thing” moment. When finally released, perhaps later this year, it could be the one of the most fundamental changes to the way mobile apps work since the App Store. What it won’t be, however, is an instant solution to the majority of app developer’s main problem: app discovery.

Let’s unpack this a bit.

Android Instant Apps, as they were presented during the keynote, will allow Android native apps to run immediately, without being installed, by essentially lazy-loading the relevant modules to the device at run-time. This will allow users to interact with your app and your content immediately, without needing to go through the hurdle of visiting the app store. Users can then (presumably) install the ‘full’ app if they want to.

It’s easy to see why this is a big deal. The mechanics of installing an app involve a lot of physical and psychological friction: do I really want this app on my phone? Do I trust it? Will I ever use it again? Do I have the time to wait for it to download and install? Do I even have the space for it? (Anyone with a 16GB iPhone can attest to this being a very real and very constant problem). Apps could lose anywhere between 20 to 80% of the traffic that hits their app store page, so anything that helps eliminate this friction will be a huge win for app developers.

Then it gets even more interesting with Android Pay. According to the keynote, Instant Apps will be able to integrate with Android Pay. If we assume this gives the app instant access not just to payment details, but identity and shipping details as well, you could easily imagine purchasing something you just discovered on the web in an Instant App with just a couple of taps.

Ways Instant Apps will help app developers

App linking will be smoother and involve less friction.
Both Android and iOS have allowed native app deep linking for a couple of OS versions now, allowing developers to link into deep content views within other apps. This generally works great if the user has the target app already installed on their device; but if they don’t, the experience isn’t so great: the user is generally redirected either to a mobile-optimised version of the target product, and usually presented with a mobile app upsell ad; or they are directed straight to the app store, where the user needs to first figure out what kind of app this is, do I care enough about it to install it, etc.

Flowchart showing how apps are installed from app links

The sloppy app-install experience from app links

Some companies have been trying to improve this process, such as who have built tools to allow developers to use ‘deferred deep links’, so that when the user does install the app after tapping a deep link they will be directed straight to the piece of content they were looking for directly after the install. But there is still heaps that can go wrong: the user needs to tap ‘install’, wait for the installation to finish, then open the app… So although deferred deep links help, they are a band-aid on an essentially sloppy user experience.

Instant apps will solve this by skipping the whole store and to-install-or-not-to-install question. Because of this, I expect to see more developers engaging in app linking partnerships and leveraging such partnerships both to monetise their own users and also to grow by seeking partners to send incoming links. The NYC-based startup Button is building an exciting business around facilitating a network of deep-link-based affiliate partnerships, and through their SDK has also tried to solve parts of the app-install problem by bringing more content into the publishing app.

Allowing easy access to rich native experiences from real world locations
Lots of brands and stores have apps already, but they all suffer from the app install friction as described above. It might be really handy to be able to place your McDonalds order in advance from the McDonalds app, but if you’re only going to McDonalds this one time, will you bother downloading the app, signing up, adding your payment details, etc?

Instant Apps would allow businesses like McDonalds to allow customers to place their order, and pay for it, quickly and easily without needing to download anything. The example Google used in their keynote was paying for parking, without needing to install any app, and – more importantly – without even needing to know which app you need. Just ‘point your phone’ at the parking meter and via the NFC connection it can figure out what app you need, lazy-load in the needed module, connect to Android Pay and – boom! You’ve paid for your parking safely and securely. Or perhaps you’re in a new city and you want to buy a ticket for the subway, but you have no idea how the system works in that city (and we’ve all been there). Just point your phone at the ticket machine, and the appropriate experience to book and pay for your ticket pops up right on your phone.

Given the ease of linking into rich experiences that this allows, I could imagine other, non-commerce use cases. Imagine Yelp issues all of its businesses a QR code. Then when you’re sitting in a restaurant and you’ve had a great meal, you could scan the code and go directly into a Yelp-powered experience where you can leave a review – without needing the Yelp app ‘installed’ on your phone. (And if Instant Apps allow users to access users’ identity, you don’t even need to create an account on Yelp either).

Preview an app without installing it
It will be interesting to see if Google build some of the Instant App mechanism into the Play store directly. This could allow you to quickly ‘preview’ an app before you make the decision to install it. Screenshots, descriptions and videos are great – but nothing beats actually using the app. What if you could preview a working version before you install?

Instant App-powered Trial Versions could become the next frontier of App Store Optimisation.

Or what if this enabled free, limited trials of paid apps? Before choosing to drop $9.99 on that newest distraction-free text editor, what if you could trial it? This could also be great for games: like Shareware for the app economy.

Will you even need a mobile-optimised website at all?
If you take all of this to the logical conclusion, you start to wonder if you need a mobile website at all. (Ok, at least an Android-optimised mobile website, for now).

These days plenty of businesses, such as Hotel Tonight, are mobile-only from day one; but for many others the web, and particularly the mobile web, remains an important discovery and conversion channel. For content-based businesses, it’s particularly important to have a mobile website to deal with the “app not installed” dilemma described above: when somebody discovers your content, either through SEO or a link from another service, you want to be able to show the user some content immediately. (Or you risk sending them directly to the app store and hoping they convert to downloading the app).

If Android Instant Apps can provide a real, native experience immediately, without downloading the app, why would you need to have a mobile website at all? You would shift your SEO focus to concentrating on Google/Firebase App Indexing, and shift your conversion funnel to the Instant App experience.

(There’s an interesting internal conflict for Google here. On one hand, Google is inviting developers to prioritise native app experiences – which when followed to the logical conclusion might very well result in less investment in the web. At the same time, Google’s control and monetisation is still heavily dependent on people searching and discovering stuff on with Google Search: one of their rationales to invest in their Accelerated Mobile Pages project.)

Where Instant Apps won’t necessarily help: App Discovery

Instant Apps could make the entire conversion experience for apps much more seamless, making it easier to access, consume and potentially test/trial apps.

But conversion is only half of the app distribution problem: the second half. The first half of the problem is app discovery, and this is where I don’t see Instant Apps helping that much – at least not directly.

Instant Apps will make it smoother to link between apps, and this could hopefully encourage a stronger ecosystem of app user/value exchange. This will help app discovery for sure. But the majority of apps are still discovered in the ‘traditional’ ways: word of mouth, content search, app store ‘browsing’, or performance/digital marketing.

Instant Apps by and large won’t let developers circumvent the traditional app discovery channels. You still need to get your app in front of a user. What it does is dramatically simplifies the conversion process, allowing more users to interact with your app and discover its value – once they have discovered it.

Things for developers to think about

What does Instant Apps mean for you? Some things to think about:

  • If you have a content or commerce-based business, start thinking about how to expand your reach through affiliate partnership building. Instant Apps will make consuming your content or service via a referred link in a partner app much easier and this can be a powerful source of acquisition.
  • Where else can you include links that could surface deep views of your service without needing an install? In marketing materials? Affiliate programs?
  • Start thinking about how to modularise your codebase now. For some apps it will be easy: Google says that some apps should be able to make the necessary changes within a day. But for other apps, depending on the architecture, it will be more complicated. Try signing up for early access to the program in the Android developer portal. But even if you don’t get in, start thinking now about how you will approach modularisation – is there a big architecture refactor you’ll need to invest in?

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

Python code


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.

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:

  • 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
  • The O’Reilly books are relatively expensive, but they’re the classics.
  • Of course, is a gold mine for budding and advanced programmers.

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.

1 2 3 4 16