How to not suck at product strategy
We’re at a time where very small teams, with big ideas, can achieve massive traction, so long as they avoid feature creep, focus on usage, and revisit old assumptions. — Des Traynor
This article is in a series of posts which are my notes from talks on product development that I found very insightful. Previously in this series:
In this post, I write down my notes from a talk by Des Traynor on product strategy in a growing company. If you would rather listen to Des speak, watch this:
The world looked very different not that long ago. If you wanted to play music, you would take a CD to a player and sit down and listen to it. If you wanted to read the news, you would pick up a newspaper and read it. You did individual activities.
Today, all of these activities look the same.
Growing a user base is easier than ever
Compared to 1999, today, there are a LOT more people online, and a majority of them are online using smartphones. So the opportunity today comes creating software and products for all these people who are online. Also not that long ago, you had to write software, burn it on a floppy disk or CD, deliver it to a brick & mortar store and wait for people to buy it.
So, a number of reasons why it’s a lot easier to grow a user base:
- Increasing in number of people online
- Increasing rate at which software can be adopted
- Increasing number and capabilities of smartphones
- Decreasing cost of creating software
- Decreasing cost of going to market
- Decreasing time it takes to gain traction
What this means to you as a product creator?
I. The metric for what mass adoption means is a lot more than than it used to be
One million people is a lot of people, but it’s not a big deal in software terms. Yo on it’s first day had a million users and Meerkat launched to a million users and hit five million very quickly.
If you look at daily active users of Slack, you start to see the possibilities of what massive growth and mass rate of adoption looks like. From miniscule daily active users in August 2013 to 500,000 daily active users in February 2015.
II. The size of the team required to achieve mass adoption has dramatically reduced
WhatsApp is the best example for this. It’s bigger than the entire global SMS system and managed to do that in less than four years. And they did this with only 30 engineers.
Very small teams with very big ideas can achieve massive traction very quickly.
What does this mean for your product strategy and what can you do?
- Fight against feature creep
As you grow your number of users, a bunch of other things grow with it — Your team grows, your vision grows, your board grows, you get more press coverage, etc.
All these new areas of growth also create “ideas sources” for things you need to create and build….as soon as possible. What the founders want to build, what the competitors already have, what the product teams thinks needs to be built — all these are new sources of ideas.
You now have a gluttony of ideas that are not necessarily bad.
If you do them all, you end up creating a Swiss-Army knife — a product that can do a lot of things, but not any of them well. If you are hosting a dinner party, you don’t use the Swiss-Army knife for a bottle opener. If you are on a first date, you don’t use this as a tooth-pick. If you are trying to cut down a tree in my garden, this is not your saw.
There are enough examples of this in software and products.
So, how do you fight and manage feature creep? A lot of lessons on how to not suck at managing products helps answer that.
2. Keep your product simple.
To keep a product simple, you ruthlessely say No to anything that isn’t your core.
If you are not convienced, checkout this awesome site by Intercom — http://www.productstrategymeanssayingno.com/
To figure out what to say ‘yes’ to and what to say ‘no’ to, answer these questions:
- Does it fit our vision?
- Will this feature matter in 5 years?
Focus on the things that don’t change — Jeff Bezos
Think of reading on a subway train. Mulitiple generations of products (book, laptop, phone, kindle) that help you do the same activity — reading.
- Does it benefit all customers?
Instead of just looking at the anecdotal evidence of when customers ask for a feature, look at the request in the context of all your customers.
Act not on the requests of your customers…but act on their behalf — Jason Fried
- Does it improve, complement, or innovate existing features?
- Does it create new usage or divide it?
Coke, when it launched Diet Coke with Lime, it didn’t create new usage, it just divided the existing users of Diet Coke.
- If this feature takes off, can we afford to support it?
- Can we design the new feature so that the reward for usage > effort required by the users?
Google Plus circles is a good example of this. A pretty useful thing to have your connections in specific groups, but the effort required to create these groups is much more than the reward.
- If we can’t do it well, it’s not a good feature.
Think of where in the value chain you can and excel at providing value.
3. Reasons to not ship software
These are some of the reasons that are never a good reason to release new software:
- “But we’ve talked about this feature forever.”
- “It’s months late”
- “We have worked on this feature for so long”
- “We can produce this feature pretty quickly”
4. It’s better to not build something in ther first place.
It is really hard to take something back from a product. The perceived value of a feature is a lot more to your customers when you sayyou are killing it.
5. Have the following “types of work” in your product roadmap
- Improving a feature (increases customer satisfaction)
- Getting more people to use a feature (increases adoption)
- Getting people to use a feature more (increases frequency)
- A new feature to support a new workflow (increases customers/revenue)
6. Focus on Engagement
Judging the success of a product team by features shipped is like measuring the success of your parenting skills by number of presents you bought for your children.
From the outside, the story of a successful startup/product looks very linear because we ignore all those decisions that were mistakes. And when we do the exercise of planning the next set of things to do, we only see the linear path and forget the mistakes that were made.
The key is that as you are going through your product journey, you are getting smarter about your product and gaining the knowledge about your space.
If you knew then what you know now, would you still have….built that feature, shipped that integration, chose that architecture, designed that screen?
If the answer is no, then get rid of it.
Hindsight is the best vision you have. The mistakes you know about and don’t correct are the ones that you are re-making, every single day.
We’re at a time where very small teams, with big ideas, can achieve massive traction, so long as they avoid feature creep, focus on usage, and revisit old assumptions.
