Product Vision and Strategy
This is a story of how I generated the below Product Vision, Strategy and Goals. Aligning with business and customer needs for a business vertical within a publicly traded company:
The above strategy is the result of multiple data gathering exercises as illustrated below.
SITUATION
As the Product Lead, I was brought in to address a neglected business by rejuvenating an events vertical (as part of parent companies Entercom and CBS), out of a decline stage back into a growth cycle, by taking a customer centric approach. Coming in with twelve plus years of formal Product Management experience. Five years of which at the world's largest live entertainment company: Live Nation (Labs)/Ticketmaster. I was confident I was going to help solve key user problems, for short, mid and long-term gain.
WHERE TO START
This vertical was once a thriving event discovery business with multiple revenue streams. Through multiple acquisitions and poor leadership, the business, its teams and its customer value were left to decay. The incurred damage of inaction required an overhaul, not just of the 10+ year old technology, but of its mindset and culture.
Represents an actual decline without disclosing the actual numbers
In a situation like this it's not good to dwell on the past, but you need to address it and ensure the learnings are clear, before the teams can move on. Recently, there had been attempts to prevent this business falling further into decline. Those attempts were ultimately approached too narrowly by teams that were not led by a product mindset, instead with a heavy "technical" or "project" focus, failing the business and more importantly the customer, driven by short-term gain. This created an environment where key people with fundamental subject matter expertise were let walk out the door. Success was measured by output of features and not by actual customer usage/performance. This presented its own set of challenges but on one hand, it gave me the opportunity to turn this around and build out a Product team. Especially since there was no true Product management organization in what had become a "top-down" feature culture prior.
“Historically, success was measured by output of features and not by actual customer usage/performance.”
QUESTIONS
Some early questions and thought process I asked before I dove into the Product Strategy generation:
- Where can this business provide value to its users again?
- Who are our customer segments?
- What problems are we trying to solve?
- What is serving those needs at present in the marketplace?
- What solutions/features will we prioritize?
- How will we measure and validate assumptions for these solutions?
- How quickly can we test, measure and iterate products to users?
- What will our main value proposition and can we be unique?
- What channels will we reach our customers through?
- How will we derive value from qualitative and quantitative research?
- What revenue streams drive the most value to the business?
- What is our budget and how will we keep costs low initially, for a healthy P&L?
- How can design, engineering and product teams work best together?
- Can we be successful in a large corporation with conflicting stakeholder goals?
- How can we acquire, activate and retain new and existing users?
- How can we rebuild the team and what immediate skills are needed?
- How will we continuously ensure our users shape strategic vision & principles?
DATA GATHERING EXERCISE
In order to better understand the business, its value proposition, the competitive landscape and the customer I set out on a data gathering exercise to start putting the pieces of a Product Vision and Strategy together. The most valuable part of this exercise is finding out who your customers are and breaking them into your top segments. Where I started digging into both the qualitative and quantitative data:
- Historical Customer Behavior Data (browsing data, analytics, Intent Signals)
- In person interviews of existing customers (Power users, light users)
- In person interviews of non-customers
- Usability testing
- Survey Data (NPS, Survey Monkey etc.)
- Insights from User Testing exercises
- Competitive Analysis Initiation
- Customer Service Data
- Sales/Advertising data
- Email Sending Platform data
- Stakeholder Interviews (KPI formulation)
- Semantic Social Media Data
The data findings allowed me take a step back and look at the broader business more strategically, rather than so tactically. As I gathered more meaningful data, I presented my findings visually with frameworks such as the lean startup canvas model, which takes a snapshot of where the opportunity and value lies:
It is very important to view the business from afar to ensure that Product and Growth overlap where possible.
This exercise empowered me to apply my experience to focus on where the opportunity lies using insights from multiple valuable sources where trends started to appear and become clear to me. The most valuable insight was identifying the top customer segments. The below segment became a major focus of attention given the majority of data points pointed towards "her":
Segmenting your users into groups will help you focus solving their needs more efficiently.
By looking at multiple data sources and behavioral data, I was able to predict that targeting this segment and demographic predominantly would allow the business to touch other top customer segments. The data led me to believe that this persona was an influential and authoritative user in decisions relating to planning things to do amongst her family, friends and parents. Referred to by some industry analysts as the "sandwich", being sandwiched between her young family and her aging parents, playing such a central role, she is seen as a key decision maker in the circle of family and friends.
This qualitative and quantitative data armed me with a high level of confidence, that targeting this segment and demographic predominantly would put the business in a strong position to hypothesize, test, learn, iterate and ultimately solve the main problems identified.
The more we captured feedback from this customer segment, the more we were able to see even more persistent trends appear from this cohort.
It is all too easy to jump into the solution space right away, start at the problem space.
Applying the Product Market Fit framework from Dan Olsen, it became clear the problems we were listening for were showing consistent signals. The features were coming in fast and we had no shortage of feature requests.
PRIORITIZATION
An important next step is setting out to prioritize features, within strategic initiatives in line with balancing the business, technology capabilities and customer needs. At this point its dangerous territory to have committing conversations with stakeholders early on without bringing engineering to the table. You need a strong engineering lead at the beginning of these conversations to balance things like level of effort vs customer delight so the business can achieve its goals in a reasonable time-frame.
I have learned from my mistakes in the past by not doing this. Including engineering early on saves so much time and allows you to get a reasonable grasp of feasibility, where you find out what's really minimal and viable. The goal is to get to market with as little as possible so we can capture rapid and regular feedback early and pivot from the beginning. The opposite of this is building a bloated MVP, that takes too long to get in front of customers and it may be too late to change direction by the time you get user feedback leading to wasted effort with minimal ROI.
Given there is a heavy business need for growth in this situation, I availed of Dave McClure's framework as a guide to help tie initiatives and features to the customer journey, optimizing the funnel and to help set valuable and actionable metric goals.
The importance of this framework cannot be emphasized enough with multiple applications in particular prioritization and growth.
By taking this approach, it can help to not only not get lost in all of the noise from the feedback sources you receive, but it can keep you focused on what matters without falling into the weeds. Early in my career, I may have stopped at this point and boldly stated that we need to complete all of the above in some kind of a roadmap (I will talk about that later). But with experience you learn that as a Product leader, you are not here to set an endless amount of features. Instead your role is to set focus and be brave.
BE BRAVE
To quote the famous poet Dylan Thomas; "Do not go gentle into that good night" (not entirely related, but I am interpreting it loosely here). I've been fortunate to have been mentored early on by strong "brave" Product leaders at the formation of my career at eBay, where you learn how to balance diplomacy with assertiveness using data and strong rationale fixated on the customer representing your team(s) through empowerment.
These leaders do not exist everywhere and in reality I have seen behavior that resembles the opposite to the above archetypes. Where Product leaders function in environments where teams are told what features to work on, as opposed to solving problems as a team. They typically operate via "committees" behind closed doors and they further advocate the top down culture of execs where roadmaps extend over multiple quarters where focus is lacking. Unfortunately, its a reality to encounter this in a Product career.
To be a true leader you need to be brave, not always say yes and understand how to say no to different audiences. I have learned that real backbone is required particularly when dealing with varying executive personalities. I have learned that the more people you try to please the less you please anybody by sending everyone in different directions. This leads to the status quo and down the line attracts B and C level players (I'll get to people and teams later on). A Product leads job is to challenge your peers, your team and the leadership to deliver the best outcome for your customer, not to tell them what they want to hear. I admit that's easier said than done in some cases and must be balanced, especially as Products role is to be a trusted partner that is genuinely committed to stakeholder/leaderships business success. Having mutual respect and trust with each stakeholder, including the senior leadership is fundamental to the above.
Plotting visual scores on the chart from users can help speed up prioritization decisions.
Aside from building relationships with stakeholders, there are some useful tools to use that can help include stakeholders and customers in the decision making process. I like the impact over effort matrix/importance over satisfaction model, the MoSCow model, the Kano model and sometimes the RICE scoring model. The former can be really helpful as you can involve actual customers and stakeholders by plotting ratings on a scale. Its particularly helpful with the aforementioned audience. Given we are targeting growth it can be helpful to place your feature concepts into three buckets:
- Metric Movers
- Customer Requests
- Delight
Adam Nash, VP of Product at Dropbox recommends this approach as great products are built on product prioritization that encompasses all three.
I have always found its a lot easier to work with stakeholders when they feel they are part of the process and decision making. Stakeholders are a lot more likely to buy in to something if they feel they have been involved and have had their ideas heard.
COMPETITIVE ANALYSIS
As we dive deeper into my analysis and Product Strategy generation, you can see another key data point, my competitive analysis. Understanding the competitive landscape of the business is critical to understanding the broader market and learning what features customers love at a macro level. Consistent themes start to emerge and applying this to the earlier data points can help further reinforce your assumptions prior to iterating on live features to users.
In this example, it was really helpful to create a dashboard of the most relevant direct and indirect competitors that could later be referenced by multiple teams, including Product, Design, Analysts etc. I added the competitors of interest (34) to the top columns and I included stakeholders input for top competitors as a source. By researching each competitor, I was able to see consistent features of importance in the row sections.
This process derived insights around competitor SEO performance, App downloads, CTA types and colors, Comscore traffic, Transaction Models, Content types, Partners etc. Furthermore, this allowed me to make decisions towards the Product Strategy relating to the industry and improving internal domain knowledge. Patterns became clear around industry trends which made for a valuable series of data points to add to the existing data points for formulation of the Product Strategy.
EMPOWERED PEOPLE
The team should be formulated as soon as possible where allowed and contribute to the Product Strategy and Vision. Throughout this process, as I have drilled deeper I was in a good position to understand the direction and goals we are trying to achieve and the kind of Product skills best needed for the team and subsequently what skills to request from engineering and design, that would be suited for the small team(s) needs. I am a strong believer in the importance of emotional intelligence when it comes to positively influencing the dynamic of team, particularly on the Product side.
Three separate small teams focused on each initiative pillar. One team of 3 engineers (2x front end, 1x back-end) to one Product Manager/Owner for each initiative:
- Supply & Distribution Team
- Conversion Team
- Engagement Team
With a floating Senior Designer, Analyst, legacy migration architecture, Dev Ops and QA. The teams are deliberately small and are focused on key problems. They are not told what to build, instead asked how can they solve for x, examples of this are clear and visible in the generated strategy for all teams stakeholders to see:
It is crucial the teams works together on coming up with solutions for the business and the customer and they need to be empowered to make decisions to solve those problems. Marty Cagan of SVPG refers to these as empowered teams vs feature teams (missionaries vs mercenaries). A big challenge is ensuring stakeholders/leaders support an empowered team culture for it to be successful. It is the Product leads job to motivate these teams and support a culture of experimentation to validate assumptions as early as possible and protect the team from top down style leadership. This is done by building confidence and trust over time through results. Agile is a good methodology for achieving this but I have never seen one way of doing agile, instead different hybrid aspects are used to achieve goals which I believe to be the right approach.
I have earlier mentioned the importance of including engineering oversight as early as possible. As I generated this plan, I was in close collaboration with Engineering and also Design heads, to limit surprises. So as we generated a strategy, Engineering was able to think ahead and foresee the tech stack, architecture, legacy migration and services needed to support the business and user needs. This also gave realistic estimates of go to market timing from the engineering function.
I have also seen cases where engineering has been outsourced via some form of an agency or nearshoring, which can serve well in certain situations, as long as they are held accountable for delivering. If not, it backfires.
(NO) ROADMAPS
In my experience roadmaps mostly become out of date the moment they are drawn up. When we create a roadmap we pretend to know so much but in reality we need to test in the market to drive our "roadmap". In large organizations you most likely will not get away from the need for roadmaps as there is a chain of command that use this habit to plan and even try and commit to deadlines short to mid-term. I have created roadmaps in the past and have learned that you cannot realistically predict past one quarter as business, customer needs and technology changes so fast.
Roadmaps can be valuable short term, but Product should have enough trust from their business to not commit to long term features.
I will concede that it is unlikely you will get around the need for roadmaps in most organizations, which is why it is so important that the team is aware of the importance of moving fast and learning from the signals of the market to allow for continuous iteration as outlined in the "roadmap". The roadmap can serve its purpose for managing up but whats really important is the teams mentality of validating assumptions early on.
FOCUS, IN ACTION
As I mentioned before, there is never a shortage of features to work on. Prioritization of these features is essential by providing empowered teams focused problems to solve within strategic initiatives that evolve into the Product Strategy and are ultimately disseminated from the Product Vision.
It is easy to fall into the weeds and lose sight of the key problems you are trying to solve. It is Products role to keep the team focused.
As you work with your team, its not only important to focus on communicating the Product Vision and Strategy, its crucial to ensure the team is motivated. By being involved in the Product Strategy process they are more likely to go above and beyond to solve important problems and exceed on their goals. It is a Product leaders role to continuously coach Product managers and help keep them focused on whats important as they conduct Product Discovery to execution. Even before your Product managers dig into the weeds and create Initiatives, Epics and Stories in tools like Aha and Jira, it is essential they are focused and guided.
I was able to ensure teams were kept small and each team revolved around assigned objectives within Product Strategy initiatives. Below you can see actual examples of how these teams experimented with solutions within the focus of the business and customer needs.
- 1. SUPPLY AND DISTRIBUTION TEAM
The Supply and Distribution team are responsible for expanding the core data product and growing its distribution via partnership growth models and driving user generated events, like a marketplace, with the goal to ultimately increase the demand curve:Experimentations
By allowing partners to use API dashboards and allow for the self service of feeds, this naturally made this vertical a destination for partners to add and promote their events. As supply increased, we experimented with ways to distribute the data extensibly off the platform:
Results
- This assigned team were able to solve for increasing inventory by 9%
- Distribution rose by 5%
- Indirect upside of increased revolving high converting traffic
- As a Product lead its my job to ensure the results are not "final" and the teams experiment with variations to impact results
- 2. CONVERSION TEAM
The conversion team are assigned with problems surrounding converting multiple sources of traffic into high yield behavior driving revenue and turning users into active customers. The goal is to take advantage of the value proposition outlined in the earlier product opportunity startup canvas. This team also has a unique opportunity to drive an "overhaul" of the user experience as they see fit and experiment with qualitative and quantitative multi-variate testing.
Experimentations
The team was in a fortunate position to have full authority over an overhauled UI once they received comprehensive user feedback where multiple concepts were tested.
By updating the user experience to be more clinical and focused on strong calls to action, they were able to aim to solve problems related to converting users to purchase tickets and improve customer satisfaction.
Experimentation is key here and a lot of assumptions were validated and invalidated through constant feedback through optimization. Tests were exposed to certain subsets of users to capture feedback as rapidly as possible.
Results
- Ticket paths 7% conversion rates
- Attracted more targeted traffic to artists they like
- Increased registrations by 2%
- Improved customer satisfaction across the board.
- 3. ENGAGEMENT TEAM
It should be noted that there are some strong overlapping between team 2 and 3. The main differentiator is that team 3 experimented more with AI generated content and optimized personalization across all platforms within the ecosystem.
Experimentations
The team was deeply involved with team 2 regarding an overhauled user experience as dependencies were "shared" between both teams to ensure alignment with their goals. Both teams brought their findings together ensuring the customer voice was represented and the business needs were catered to.
Initially focused on content delivery to users at the right time via artificial intelligence based on complex data sets related to user groups, their behavior and their predicted behavior.
For this to be achieved a deep dive was required on user management, data warehousing and simulated artificial intelligence. In order to move the needle on engagement it was necessary to take a step back and understand how to best serve users content personalized for them, without them even knowing it.
The more touch points we had with the customer the more we learned. We tested targeting content to user segments across email and app notifications related to artists and music they were interested in. The app naturally contributed strongly to giving insights to logged in users as a testbed.
Results
- Doubled time of user engagement on all platforms.
- Drove user input capture by 24%.
- Increased registrations by 14%.
- Email open rates rose by 2%.
- AI driven content outperformed existing content by 39%.
GO TO MARKET - GROWTH
A lot of Product managers do not get enough exposure to GTM activities, especially in larger companies. As part of the Product mindset, Product managers need to engage in GTM thinking and strategy throughout the process and not just at the end. A Product manager is not responsible for just pushing out features, instead they are responsible for the overall success of the Product within a larger ecosystem. You can see an example of this that I showed earlier in the prioritization section by using the AARRR framework to group your features into the buckets that contribute to growth such as Acquisition, Engagement and Retention.
Success can mean different things to different people but what ultimately really matters the most is whether or not enough people will actually use your product and how often. Growth is a cross functional effort. It requires Product Design, Data Science, Engineering and Marketing all working together and each team needs to be aware of what goals will drive growth for the product. Knowledge of metrics such as Cost Per Acquisition (CPA), Customer Acquisition Cost (CAC) and Life Time Value (LTV) are fundamental.
Below you can see an illustrated example how we put our marketing hats on in action and not only focused on problems to solve for the customer but also on how we can be cognizant of how to grow our product usage and the business using existing channels.
To close, all of the above is great as long as it is focused and aligned with your Vision and Product Strategy. The strategy is not written in stone and learnings need to be applied and the strategy adjusted if necessary. Ensure Product members are able to contribute to the Product Strategy and Vision, so they feel that they are part of the process. Above all, the product cultural mindset is your biggest ally as a Product lead and that needs to be encouraged and protected. A great way to continuously reinforce this is what I constantly remind my team of: ABM (Always be measuring):
*Elements of this example and numbers have been adapted and blurred to protect and ensure confidentiality.