Who has time for strategy?
Vision and strategy have, to the detriment of some companies, become buzzwords. The kind of words that people hear, but don’t really acknowledge like gourmet, or deluxe. There is no time to strategise or come up with some airy vision they say, there is too much stuff to do, and by stuff we mean wireframes, mock-ups and features. But an overemphasis on feature delivery will ultimately result in bloated, difficult to use products nobody wants, and, as these products fail to impact measurable strategic goals, will be the downfall of many product teams and companies.
So how have we found ourselves here?
Valuing the wrong things: Like a manager who measures time spent in the office over outcomes achieved, it’s all too easy to start to measure a team’s tangible ‘output’ and forget about the bigger picture of moving closer towards a goal, and gaining a couple of inches on their journey. Delivering one feature that gains 1% on a key metric, is infinitely better than delivering 10 features that achieve no tangible outcome.
“Never mistake activity for achievement” (basketball coach, John Wooden)
Fear: Defining your product vision, and a strategy to get there, takes time, and it’s all too easy for this time to be viewed as not ‘work’ or just ‘blue sky thinking’ since it produces no polished mock-ups or new features. There can be a fear of what executives will think if they don’t see anything working or any tangible ‘deliverables’.
Arrogance: The feeling that we’ve been around long enough to know the market, know what customers want, and therefore start to base decisions on gut feel rather than customer feedback and data. As a result we start to chase short-term gains and delivery, rather than thinking about the overarching goals it should all be contributing towards.
It’s tricky: When it comes to it, questioning what is really important needs input and direction from multiple teams and customers, and should take into account the competitive landscape. Delivering feature after feature without stopping to question why or measuring the impact is easy, but isn’t going to end up with a great product.
Why is a vision necessary?
You align your product or company around a purpose, not a fixed solution. In reality, what you are building and how, will and should change over time, particularly early on. But the reason you get up in the morning and start work should remain the same.
It increases team engagement. If teams are aligned by a higher purpose they understand and have a say in directing, they will be happier and more engaged in their work, and create a better product. It’s hard to get excited about going somewhere, when you don’t know where it is you are going.
Why is a strategy necessary?
A strategy can provide a shared direction of travel for a whole company or team, it will help everyone understand the steps needed to move closer to your vision, and how you will measure success along the way.
This is particularly important, as it helps avoid using ‘vanity metrics’ to track progress. They might make one team or individual look good, but not represent real progression for the product or help the team make decisions. For example, measuring ‘app downloads’ might look impressive and mean that the marketing folks are working their magic, but what are these users doing that’s meaningful with the app once it’s downloaded? Are they spending money? Inviting friends? Think about what the real indicator of success for your product is.
You’ll find saying ‘no’ and making decisions becomes a lot easier when you have a strategy, created in collaboration with your stakeholders and importantly, customers, to guide your roadmap. Everything on there should be justified by its ability to get you closer to your team’s goal (be it higher revenue per user, less errors, or higher basket value). Any new ideas are validated against their ability to deliver against this strategic goal and if they don’t, they are out!
In doing this, you should buy the team some freedom to determine the solutions. Often, an overemphasis on tangible output is compensating for a lack of strategic thinking. If you have found yourself in a position where ‘feature requirements’ are fed down from above for the team to deliver, and have dreamed of getting the autonomy the team deserve, agreeing measurable strategic goals with your stakeholders should give them the comfort they need to let the team determine the ‘how’.
Where do I start?
The vision of is the ultimate goal you want your product or service to achieve. This should be high-level and aspirational enough that it inspires the team working on it, even better if it aspires to a higher purpose that make the world a better place for your customers.
If there is a company vision, the product vision should be aligned with that. If the product is the company, then it should be the reason the founders started the company in the first place. For example Google’s company vision is: “To organize the world’s information and make it universally accessible and useful”. Immediately you can see how this is the common thread between search, gmail, photos and drive too, but it doesn’t state how, rather, it’s a north star for everyone in the company to align towards. Roman Pichler has some great tips on building a product vision.
Coming up with this statement should be a collaborative effort between stakeholders, but also the people doing the work too. Consider running a visioning workshop to get started.
“We are stubborn on vision, we are flexible on details” — Jeff Bezos, Founder & CEO at Amazon
If the vision is the destination, then the strategy is how you get there. In essence it’s the building blocks that will move you towards your vision for the product or company. Again, make defining this as collaborative as possible, involving the more senior folks, but also developers, designers, and anyone who will work on the product. They all need to be fully bought into the strategy to do their best work.
There is a great lightweight framework by Melissa Perry from Produx labs, who uses the product strategy canvas to help teams outline their strategy.
The idea is to help the team identify the starting point they need to take them closer to the vision. How they tackle this should not be output led like ‘build a mobile app’ in the hope that will attract more users, but rather, outcome led like “increase registrations by 20% by July 2018’ which leaves the team plenty of room to experiment and find the best way to hit this target.
Once you have defined your initial strategic goal, think about what you need to do first, which should be fed by plenty of feedback from your users. Continuing the sign-up example, after speaking with users you might find that the loading speed of the signup form is so slow, people are giving up and leaving. In which case your first ‘target condition’ might be to ‘reduce page load speeds to an average of less than 1 second by December 2017’ knowing that your current state is an average of 5 seconds.
These numbers should be agreed with your stakeholders, and should give them confidence to step away from focussing on outputs like wireframes and features, and focus more on the outcome the team are achieving, which leaves the team free to find the best way to meet the objective.
In his book “Good strategy, bad strategy” Richard Rumelt refers to the “hierarchy of objectives”, where high level company goals help align individual product teams, who can then set their own, more granular goals to contribute towards those. For example, a company goal might be to “gain 20% market share in China by December 2018”. The mobile product team might then look at how they can better localise their offering to improve the experience for Chinese users. One of their goals and measures of success might be to “increase referrals by Chinese app users by 35% by July 2018”.
Getting a clear, well understood vision and strategy in the minds of all the people involved in building a product, will take the conversation away from button colours, mockups and tangible outputs and make it about outcomes and metrics; meaning more freedom for creativity within teams, faster decision making, and a better product too. It’s not an easy task, and will take time in a company more used to top-down requirement setting, but gaining autonomy is all about building trust, so keep at it. If you can demonstrate progress against strategic goals within one product area or team to begin with, you’ll find you gain the trust of your stakeholders, and soon you won’t be talking about the tactics of getting stuff done, but rather, how the things you are building, are the right things, and how they can contribute to the success of your product and business.