Product Vision: Speak Language People Will Understand
In this article, I’ll share some lessons learned by adapting an existing digital product for new customer segments.
I’ll keep this article not attached to the product itself but in the process of building it and it’s the current process up until now.
It’ll describe some points divided as follows:
- Setting the product vision
- Getting people onboard (stakeholder management) to make it happen
- How to talk with other areas to get to this vision
Why is setting a Product Vision important?
As a product manager, you should know and be able to communicate with others which direction your product is heading. Of course, you won’t always be right, but having intuition will not only help you make better decisions but get the people around you on board with this vision as well.
This is especially important since the daily life of a PM is chaotic, and it’s easy to be overwhelmed by people asking for features or telling you directions about where your product should go. Defining and documenting a product vision will help you and the people around you understand how to move closer to the product and company vision.
How I Went About Creating a Product Vision
To start thinking about it, I first read a lot of things about how technology is changing in the next five years and tried to identify what behaviors/trends seemed to stick.
This research was based on areas that are either directly or indirectly related to my product. Right now, they may not converge, but it’s interesting to imagine how they can converge if a problem could be solved better.
An important thing to point out here is this research can also be done outside the internet. For instance, if you would like to learn more about voice recognition, find in your contacts who are working on that to give a “mini-class” about what they’re working on and how the field it’s evolving.
After that, I spent a few weeks writing down how this future could be. To start this exercise, I didn’t worry about if we would have money and people to make it happen. The process went free and without restrictions.
To document my thoughts, I used a mix of post-its, text, and some kind of connection between the ideas. You don’t have to be attached to a particular tool, but I used Miro to help to do that for this exercise. However, this process could just as easily be done on paper. Sometimes it can even be better since it limits distractions in this immersive process.
The important thing for me was to think about it for only a few hours each day and not consume my whole day with it. This helped me think more holistically about the product and gave me time to creatively think about the product across different days.
Why it’s important and what can be a “simple” deliverable
Product vision should be an easy sentence to remember (inspirational slogan) and product strategy should be the work that has to be done in to get to this vision (more on that below).
Since a product manager is not an actual manager of anyone, people have to trust and understand the vision you provide them. This is even more necessary if your company has many different teams that are not integrated into cross-functional squads, which creates challenges to get people on board. This also happens because other areas will have their roadmap, so getting people to commit with yours can be challenging if it conflicts with their team roadmap.
Getting people on board
It’s important to be clear that a product manager cannot deliver a product by themself. She/he will deliver a product with other people’s help, so it’ll be easier if you have a great product vision and understand how to relay that using “other people’s language”.
So, I’ll dive deeper into what are some real-world scenarios that I’ve used to get people from many areas on board to get a better product in the customer’s hands.
Speak language other people understand
You’ll need a lot of cooperation from different people from different areas, so it’s important to understand what it’ll make them successful by helping you.
Customer Success (CS) Team
Imagine that you need to do Product Discovery for a new feature and you need a group of customers to help evaluate. You could always try and approach an unknown customer and hope it goes well, or you could just ask for help from the CS team whose job is to talk to customers every day.
Ideally, a CS team will have a good set of customers that they know can help you or can be approachable right now. You also want to make sure you understand the context of the customers may refer you to — for example, if the CS team introduces you to a client frustrated with an existing part of your product, they will probably not be a good source for feedback for a newer product until their initial issues are resolved.
So, in this scenario, you both get a benefit. You’ll be able to talk to someone who can provide you with interesting feedback, and the CS person can improve customer health score by showing how the product it’s evolving.
Engineering Team
As a PM, you should give the engineers as much context as you can around the product they are helping build: business strategy, involved people, current market, C-level expectations, current financial metrics of the product, and so on.
By giving context in what they’re doing, it’ll be easier to explain what direction the product is going and most importantly why the product is going in this direction. By doing this, you’ll also find people will start to be more autonomous in technical decisions and not rely 100% on the PM for all decisions.
If you’re responsible to make sprint planning and describing what should be done in the next weeks, I’ll share some important hints:
1- Every story/card/epic (you pick what fits for your case) should have metrics associated:
For instance, our product has to send emails to customers. But, people were not opening our email at a rate that we’re expecting. So instead of proposing a solution for engineers (for instance, to ask them to send emails only during the day at a working time), we committed in a sprint to “increase the email open rate”. When we refined this story, they were able to think not only in a lot of solutions for that particular timebox but also a metric to check if they were being successful or not.
So, not only having the business context in mind but a clear (and easy to measure) associated metric was our common language to speak with.
2 — Have business goals for every sprint:
This one sounds obvious but, usually, Jira or Trello (our most commonly used tools to keep track of sprint) doesn’t have a special place for that.
So, in every sprint planning, we write what the business expects from that sprint. For instance: “user should be able to send an email”. To accomplish that, maybe engineers will have to develop a lot of things in the back-end and front-end that are split into many smaller stories. So having a “user-level” or “business-level” goal setting, people can understand better how things should be put together and why. This hint is joint with the first one, but I think that they’re so important that they should be described in separate views.
3 — If you use Scrum, have consistency with schedule
Again, it seems obvious but if you commit to having a daily at 09:30 AM, you should do that at that specific time. A product will take time to be done and discipline it’s required for that. Being consistent with engineers with an agenda will help to keep things on track.
Sales team
It’s a good exercise to talk with salespeople for them to explain their daily-monthly workflow. You can see that work in sales can be very stressful. Sales staff always have a sales goal to hit, need to pitch a product for a market that changes every day and understand their customer needs to see if the product will solve that business need (among other things).
With all of that in mind, it’s pretty important for them to understand what the product does, how it should be presented, how it differs from competitors, how they can charge customers for that, and what are the current costs from the product.
To accomplish this goal, I’ve made a spreadsheet that contains:
- Current product costs: infrastructure, cost of other tools that we use (and how this costs scales as customers come in), people involved (engineers, designers, PM)
- Current competitors and how they charge for their products
- A pricing plan proposition: Presenting different prices and what features should be included in each plan.
With this spreadsheet, we’re able to talk about what our product can do for different company sizes, how it can be presented for different size businesses, and how sales can best demo it for their clients.
After that, we could talk with each other in terms that we both understood.
Scarce resources
One thing that many PMs struggle with is how to accomplish a product vision with limited resources. You’ll not always have all the developers, all the designers, all the marketing, and so on. So, when you’re not in charge of hiring more people and the company will not be able to do so for a while, you’ll have to find ways to be creative.
For instance, right now we don’t have a dedicated Product Designer for my team, but one day when I was talking with developers from my team, I overheard that our front-end developer read a lot about UX/UI and wanted to do more design work. So for now, he’s our new designer and is getting coached by the Head of Design.
So when you talk with people that are working on the product, you can identify either some deficient areas in your product development and know what people like and are capable of doing as well. When you have scarcity in your product (and you will), having this ability to listen and fit people will help you to deliver a good product with your current team.
A product that everyone participates
Since a product manager will only deliver a product with other people from different areas and backgrounds, I wanted to show how important it is to get people on board for it and what format can be appropriated for each one.
Of course, it should be adapted in different companies, but this exercise to find the ways that you can approach other people it’s a huge part of a Product Manager job!
PS1:
This article was made with the guidance of Matt Grierson. Through the first semester of 2020, I have the opportunity to participate as a mentee in a program called The Product Mentor, a program designed by Jeremy Horn to pair Product Mentors and Mentees from around the World, across all industries, from start-up to enterprise, guided by fundamental goals: Better Decisions. Better Products. Better Product People.
I’m more than grateful to have this guidance for so much time.
PS2 :
In the process of writing this article, I read a lot of articles mainly from Marty Cagan and Melissa Perri and I also had new experiences at my work. Besides, of course, the mentioned guidance.
Whenever I read one text or had another experience, I wanted to change this text, making it harder to “finish” it. So, this text is not the final version, but the current one ( or version 1.0 of it).
