VP playbook for developing a product strategy OK, here's the scenario: You're a new VP Product and need a product strategy fast. What do you do? Playbook: 𝟭. 𝗨𝗡𝗗𝗘𝗥𝗦𝗧𝗔𝗡𝗗 𝗥𝗢𝗟𝗘 What is the ratio of product/tech to marketing/sales? You can do this by cost or headcount. (Ignore operations for now.) This signals what your role is. Talk all you want about the importance of a product-led culture. More often than not this is baked into the company through headcount. You can't be product-led if you have twice as many sales reps as engineers. S&M > product • "Sales-led" • Role: keeping the lights on • Time will be mainly fielding sales requests and supporting existing product. S&M = product • Balanced org • Role: incremental innovation • Can take on 1-2 major product initiatives as well. Product > S&M • "Product-led" • Role: major innovation • You're driving the strategy and need to have a vision for where the company is going and how to move major business metrics. (gulp) 𝟮. 𝗘𝗦𝗧𝗔𝗕𝗟𝗜𝗦𝗛 𝗕𝗔𝗦𝗘𝗟𝗜𝗡𝗘 Understand how the product org currently spends it's time. Track number of story points / tickets / developer time on: 1. Fixing bugs (unplanned) 2. Tech debt (planned) 3. Sales requests (unplanned) 4. Strategic product work (planned) How much planned work did you ship in last quarter? You can make incremental changes to this only. “Stakeholder demand does not drive output” You should start to have an idea of what you can get done in the next quarter (Assuming we don't have time / budget to radically change team size) Use this tracker: https://lnkd.in/e2wN-2hK 𝟯. 𝗦𝗡𝗔𝗣 𝗦𝗧𝗥𝗔𝗧𝗘𝗚𝗬 Speak to 2-3 key stakeholders (e.g. CEO, CRO, CMO) Write up your understanding of the context and strategy in 1-2 pages: • Objective - What are we trying to achieve (quant + qual) • Context - What is market, funding and internal situation • Pillars - What are 2-3 biggest themes of work that need to get done Your pillars might include: • Goal - Purpose of this theme • Metrics - How you measure success • Rationale - Why this makes sense • Example features - Not commitments, but help align on what we're talking about Share with as many people as possible for feedback (as a VP, start at top of org) Simplify this template: https://lnkd.in/eidd3E7g 𝟰. 𝗥𝗘𝗦𝗢𝗨𝗥𝗖𝗘 𝗔𝗟𝗟𝗢𝗖𝗔𝗧𝗜𝗢𝗡 Have a workshop with execs to agree how you split existing teams between: • Strategic pillars • Ad hoc sales requests • Tech debt (i.e. increased velocity in future) Discuss % and convert to teams later. “If it’s not painful, it’s not prioritisation” This should be a leadership group decision. As Product VP you should enable smart decisions. Don't let wishful thinking flex capacity estimates.
VP playbook for developing a product strategy
More Relevant Posts
-
I had a coaching call recently where a product leader told me he had 100+ items in his backlog. Sales was pushing for custom features. Marketing had urgent requests. And he was drowning in what he called "a nightmare to deal with." The problem wasn't that he had too many ideas. The problem was that he was evaluating every single one the same way, estimating effort and calculating impact before asking the most important question: Does this even align with our strategy? So I introduced what I call the Vision Filter Framework, which is something that evolved from my time at Sonos. It's dead simple: 1️⃣ Strategic Alignment: Does this move us toward our vision, or away from it? If no → Stop here. Don't estimate the work. Don't calculate ROI. Just say no and move on. If yes → Continue to step 2. 2️⃣ Business Impact: What value does this actually create? 3️⃣ Level of Effort: What will this cost us? Here's why this order matters: You can have requests with huge business impact that are still the wrong move for your product. If your vision is to be a cloud-based, AI-powered B2B service, building custom Excel upload features for one big client might generate revenue today, but it pulls you off course tomorrow. Strategic alignment isn't just another dimension to weigh. It's your first filter. It saves you from wasting time analyzing ideas that should never make it onto your roadmap in the first place. And it gives you a defensible way to say "no" to stakeholders, even when they control the revenue. If this resonates and you'd like to learn more about how to apply the Vision Filter Framework to your specific situation, drop a comment below or send me a DM.
To view or add a comment, sign in
-
-
Our roadmap doesn't belong only to the product team. It belongs to the entire company. When I was tasked with creating Expandi's roadmap, I knew exactly how I wanted to approach it. At my previous startup, we'd already cracked this. The roadmap lived in Jira Discovery where everyone could see it - Sales, CS, Marketing, the whole team. Because product isn't just the development team. Product is everyone who touches it: → Sales sells the product and knows what blocks deals → CS helps customers win and sees where they struggle → Support solves customer problems every day → Marketing tells the product story to the world → Leadership aligns resources and makes tradeoffs So our roadmap works like this: Sales influences priorities based on what's killing deals. CS highlights where customers need more support. Marketing knows what to build buzz around pre-launch. Leadership = resource allocation and timeline tradeoffs. The roadmap lives where everyone can access it. Not buried in some product team Notion page. A roadmap only the product team sees is just internal documentation. A roadmap the whole company owns becomes a growth engine. Because we're not building features in isolation. We're building solutions to real problems that real customers will pay for. And the people closest to those customers usually aren't in product meetings. PS: What’d your take on this? Lmk below!
To view or add a comment, sign in
-
-
Sales enablement needs to think more like product managers. Too often, enablement is seen as the team that just builds decks or runs training. But that's not our full scope of value by any means. What makes a product manager effective? They listen to users, study workflows, spot real problems, and roll out solutions that actually help. Imagine if enablement worked this way. Start by treating your sellers like customers. Sit with them. Ask about daily blockers. Watch how they use your resources and where they get stuck. Design new processes or tools with their feedback in mind. Don’t just launch and forget, track adoption, see what lands, and tweak what doesn’t. If something falls flat, own it and fix it. Keep listening, keep iterating. I have learned to always launch a test group for any kind of new tool, methodology, or playbook. So much easier to spot these issues early on and fix them before the rollout is widespread. This is how enablement stops being a background function. It becomes part of the sales engine. Reps trust you because you solve real problems and give them what they need, when they need it. Think like a product manager. Build enablement that delivers outcomes, not just assets. Your sales team will notice the difference. 👀
To view or add a comment, sign in
-
People with 10 years in product management still take orders instead of calling the shots. You know the signs: - Leadership treats you like a middleman, not a strategist - Your roadmap gets dictated by sales requests - Engineering pushes back on every timeline But here's what I learned after watching dozens of PMs break through: The difference isn't experience. It's influence. Here's how to shift from order-taker to decision-maker: Step 1: Own the "why" before the "what" Stop accepting feature requests at face value. When sales says "customers need this integration" → Ask: "What outcome are customers trying to achieve?" When leadership demands a timeline → Present: "Here's the business impact of different approaches" You become indispensable when you translate requests into strategy. Step 2: Build your coalition before the meeting Influence happens in 1:1s, not conference rooms. Before any major decision: → Align with marketing on positioning → Talk to engineering leads about technical feasibility → Understand sales objections and customer pain points When you walk into that room, you're not presenting an idea. You're presenting consensus. Step 3: Make data your default language Opinions are debatable. Numbers aren't. Instead of "This feature will improve user experience" → "This addresses the #1 support ticket category affecting 23% of users" Instead of "We should prioritize this" → "This moves our north star metric by 15% based on similar implementations" Why this works: - Strategic thinking → you're seen as a business partner - Clear reasoning → harder to override your decisions - Stakeholder buy-in → less pushback, more support Senior PMs don't just manage products. They shape business outcomes. If you're tired of taking orders, start building influence. Your experience deserves more than execution.
To view or add a comment, sign in
-
Biggest killer of SaaS growth…? 👉 Marketers asking: “what’s on the product roadmap?” If you’re hearing this, then there’s a cultural issue in the company. And it’s going to place a (very) low ceiling on growth opportunities. Too often marketers are handed the finished product and asked to *promote* it. Then get blamed when nobody buys it. Truth is, marketing is a company-wide effort. It’s how one company beats another. And everyone plays a role. The fastest growing SaaS companies do things differently. They start with alignment… – Product & Marketing are equal partners and always in sync. – Marketing influences what gets built BEFORE development begins. – The product teams are shipping regularly and often. – Both teams bake in customer feedback loops. – They listen to customer feedback & validate it TOGETHER. There’s a lot more but you get the picture. It’s this togetherness that creates MOMENTUM. And that’s how you win today. Stop with the crayons. #saas #marketing PS. It’s on the CEO to align the two. And do all they can to influence this culture within the company. No excuses.
To view or add a comment, sign in
-
Structure Builds Outcomes I’ve seen brilliant Product Marketers fail for one reason: they treat every launch like it’s the first one. And I’ve seen good PMMs become excellent when they stop reinventing the wheel. The “this time is different” syndrome Creativity in PMM is overrated. Or rather, it’s misapplied. When something works (a messaging framework, an enablement process, a way to engage stakeholders) the temptation is to improve it. Make it more creative. More personalized. Wrong. The best PMMs are orchestra conductors They don’t improvise the symphony every time. They have the score. They know which instruments come in when. The job is to execute with precision, not redesign the system. Creativity is reserved for what truly needs it: how you position against competition, what narrative you tell the market, how you differentiate when everyone says the same thing. But the process of how you launch, how you enable, how you sync with product and sales? That gets systematized. The real trade-off Systems limit flexibility. And that’s uncomfortable. Product will want “a fast launch but big.” The system forces you to say: pick one. Sales will want “just this deck, customized for this deal.” The system says: use the standard, customize only this slide. You’ll have those conversations. But it’s better than living in perpetual chaos. The question that matters Which parts of your function are repeatable and which require original thinking every time? For me: systematize the launch process, enablement structure, and stakeholder rituals. Keep positioning, competitive narrative, and messaging original. If you can’t answer that question, you’re probably reinventing things you already solved. Structure builds outcomes. Outcomes build careers. Drop a comment with what you’ve systematized in PMM that actually moved the needle. I’m curious what’s working for others. #ProductMarketing #GTM #ProductManagement #B2BSaaS #MarketingStrategy
To view or add a comment, sign in
-
What does a product launch process actually look like? Like most things in Product, it depends. 1️⃣ At Onfido (my previous company) We were building identity verification products in a highly regulated space. There were legal, compliance, and privacy requirements to meet. So we: - Structured the process around 4 phases (pre-alpha, alpha, beta, and GA) - Defined decision criteria to move through phases - Aligned on what “ready” meant - Created templates so teams knew what to do for each task - Set up a steering committee to guide investment and launch decisions - Involved sales and CS early, especially during beta 2️⃣ At Anaplan (my current company) We bring dozens of products to market every year. The challenge isn't regulation, but coordination. So we: - Mapped every step to GA, from enablement to pricing to partner readiness - Aligned those steps with product development phases - Made roles and responsibilities crystal clear What a good launch process looks like depends on your business, but it always includes cross-functional readiness: ✅ Are you in a regulated industry? You’ll need legal and compliance signoff early. ✅ Do you have a sales team? You’ll need demos, decks, and clear messaging. ✅ Every business needs marketing aligned, pricing defined, and support trained. And the final question: where should the process live? It might be in Product Ops, GTM Ops, or Marketing. But too often, it lands on the PM’s plate, simply because no one else is set up to own it. What do launches look like at your company?
To view or add a comment, sign in
-
-
🪦 Hills I’d die on...if I wasn't so afraid of death... Spend enough time in marketing, and hot takes become personal mini laws. I’ve been doing a lot of learning and reflecting lately. 💞 And like any good self-improvement nut, I’ve turned that reflection into structured guardrails...mostly to avoid repeating mistakes (and to help others avoid them too). So here are a few of my hills. Slightly spicy. Fully backed by trauma. 😉 1️⃣ Stop expecting teams or Leaders to know that messaging ≠ copy. Yes, we as PMMs know ≠ copy. But oftentimes, stakeholders don't. It's on us to educate them. 2️⃣ Your product roadmap will change. I have officially stopped pretending otherwise. And no, the final product rarely looks exactly like the scope doc. That’s called reality, not failure. 3️⃣ Sales enablement is not a one-and-done training session with your CPO. Enablement is a process, not an event. Stop expecting your sales teams to “get it” after one sesh. (Or two, for that matter!) 4️⃣ Most teams build personas before they’ve nailed their value hypothesis. Before you name “Start-up Sara,” figure out and focus on: >> Who feels the problem most acutely? >> Why are you uniquely suited to solve it for them? Personas help clarify your execution. But they shouldn’t replace your strategy. 5️⃣ You don’t need 20 interviews to find the truth. You need 5 or 6 good ones. Clarity comes from patterns, not volume. 6️⃣ Good messaging makes people feel understood, not impressed. You’re not writing for your competitors. You’re writing for confused buyers. Stop data-dumping stats. Start relating to their challenges. 7️⃣ A product demo with no narrative is just a tour. Don’t just click around. Show me the story: where I am today, what’s in my way, and how your product changes my day-to-day for the better. 8️⃣ Customer quotes are not messaging. They’re validation. Useful, yes. But a great quote won’t save a weak narrative. What from my list above do you totally disagree with? 🤔 #productmarketing #marketing #PMM
To view or add a comment, sign in
-
most GTM teams don’t fail because of bad marketing or weak sales. they fail because they’re selling a product they’ve never actually used. I’ve seen this pattern: teams speak in slides, not in experience. when you only know your product through a pitch deck, you’re selling the idea of it, not the reality of it. and that’s when the disconnect begins: between promise and experience, between growth and churn. true growth starts when every person in the company, from Sales to Design to Customer Success, experiences the product, not just talks about it. because if you don’t know the product like the back of your hand, you’re already failing at your job. I wrote about this mindset shift and why I believe product fluency is the new growth moat. read about it here: https://bit.ly/3IUILQj
To view or add a comment, sign in
-
Product teams often build in a bubble. Here's the pattern I keep seeing—and a simple fix." We validate the problem thoroughly. User interviews, data analysis, competitive research. We know the pain is real. Then we build the solution... and hand it to marketing and sales. Hope for the best. Three months later: slow adoption, positioning feels off, the GTM motion isn't working. Sound familiar? I came across an article about founders using "advisory boards" to stress-test strategy, and it got me thinking: why don't product teams do this before committing engineering resources? What if, before building that new pricing model or PLG motion, you talked to someone who's actually done it? Not a consultant—someone with real scar tissue from taking a similar product to market. The article suggests something simple: send them a one-pager with your goal, plan, specific challenge, and two direct questions. Respects their time. Gets you actionable feedback, not generic advice. How do you validate your solution strategy before you build?
To view or add a comment, sign in
Explore related topics
- How to Drive Product Strategy as a CTO
- How to Implement Product-Led Growth
- Product Development Timelines
- How to Align Product Strategy With Business Objectives
- Aligning Sales Playbook With Company Goals
- How to Build an IT Sales Cadence
- Strategic Focus for Product Leaders After IPO
- Agile Product Roadmapping