Before we get into it, please know this isn’t about one specific situation, but it’s a recurring pattern I’ve seen firsthand, heard from other PMMs, and watched unfold repeatedly. And it’s definitely not true of every org.

In my first official PMM role at a midmarket, ‘old-school’ SaaS company, we worked with two types of product managers: a technical PM and a commercial PM.

The technical PM owned product delivery: engineering, integrations, and ensuring the product experience aligned with back-office operations and processes. They weren’t just focused on execution, they were thinking about how to build a scalable, reliable foundation that could support growth and long-term success.

The commercial PM was responsible for commercial success: pricing, the feature roadmap, sales feedback, competitive positioning, and aligning product decisions with broader market needs. They weren’t just thinking about what to build, they were thinking about why it mattered and how it would drive growth.

And then there was us, in product marketing, driving product launches, positioning and messaging, sales enablement, marketing campaigns, and making sure everything connected back to the business impact.

The shift from specialization to survival

But over the last 10 years, both PMs and PMMs have been stretched thin, forced into becoming jacks-of-all-trades. Especially in startups, where companies prioritize agility and speed over clear specialization.

PMs were told to be the ‘CEO of the product,’ PMMs were handed the lofty title of ‘CMO of the product.’

But what actually happened? The ‘CEO of the product’ role was left vacant.

Sales leadership stepped into the gap, not because they were best suited for it, but because someone had to own the business outcomes. When short-term revenue wins became the priority, long-term commercial strategy fell by the wayside.

Product managers became backlog managers, caught in the cycle of delivering features without owning their impact. They do discovery, they ensure good UX, but they rarely drive the commercial outcomes that define a product’s success.

And on the product marketing side, the ‘CMO of the product’ title never really materialized. PMMs got spread even thinner, expected to cover enablement, demand gen, launches, and GTM without real influence over product strategy. We bring market insights, positioning, and messaging, yet too often, we’re left applying a coat of polish to decisions made without us.

The problem: execution without strategy

So instead of a true “CEO-CMO” partnership driving the product, we have two roles drowning in execution.

Reacting instead of leading.

Shipping instead of shaping.

Disconnected from what actually makes products successful: a sharp vision, disciplined execution, and a clear path to commercial impact.

It’s time to demand more

PMs need to do more than deliver features, they need to own the business outcomes.

Every roadmap decision should be taken with revenue impact, competitive differentiation, and market positioning in mind.

If they’re not thinking that way, they’re not doing their jobs.

PMMs: take back your influence

Stop waiting for a seat at the strategy table. Take it.

Force commercial thinking into roadmap discussions. Challenge feature priorities that don’t drive growth, and ensure the product isn’t just built, but built to win.

Otherwise, we’re just putting lipstick on a backlog. The best PM-PMM partnerships don’t just ship features. Together, they shape products that win.

Thanks for reading! Let me know what you thought – find me on Twitter and LinkedIn.

P.S: If you enjoyed this post, will you share Building Momentum with your network?

The post Your PMs need to step up: demand more from them appeared first on Building Momentum.

Let’s get one thing straight: Product Marketing does not own product launches.

Sure, PMMs handle the launch plan, messaging, GTM strategy, and enablement, but if a launch is treated as just a marketing exercise, it’s already doomed. A successful product launch is a full-company initiative.

Too many PMMs get stuck in the “feature launch” grind, pushing out blog posts, crafting sales decks, and running internal enablement. They’re optimizing for activity, not impact. A true product launch isn’t just a bigger feature release; it’s a business-level event that requires company-wide alignment and execution.

Product launches need more than PMM hustle. They require leadership, influence, and cross-functional ownership. So how do you make that happen?

Feature launches vs. true product launches

PMMs often focus on shipping feature updates, launching one-off marketing campaigns, and moving on to the next thing. But feature launches aren’t the same as full-scale product launches. This cycle creates tunnel vision: ship a feature, make a marketing splash, move on.

A successful product launch is not just about announcing a new feature, though that’s part of it. It’s about creating market impact. Without a strategic approach, a launch fails to gain traction, teams operate in silos, and the product struggles to achieve its business goals.

What makes a product launch different?

A true product launch is a business event that drives adoption, revenue, and strategic positioning. It requires:

• Product readiness and differentiation: The product must be both technically sound and positioned in a way that clearly sets it apart in the market
• Pricing and packaging strategy: Clearly defined pricing tiers, upgrade paths, and value-based messaging must be finalized before launch
• Operational readiness: Finance, legal, and RevOps need scalable pricing models, CRM configurations, and compliance reviews completed ahead of launch
• Sales enablement: Sales teams must understand the product’s value, competitive differentiation, and how to confidently sell it
• Customer success preparation: Onboarding materials, training sessions, and proactive engagement plans must be in place to drive retention
• Coordinated marketing execution: Multi-channel campaigns must align with sales efforts, market timing, and customer needs

If these foundational elements aren’t in place, the launch is just another announcement.

Leading a product launch without authority

Influence is more important than control when leading a successful product launch. You won’t always have direct authority over every team, but you can drive alignment, accountability, and momentum by setting clear expectations and ensuring everyone is rowing in the same direction.

Define what success looks like

Every team must understand what a successful launch looks like beyond just launch day. Success isn’t just about press coverage or website visits; it’s about customer adoption, sales impact, and long-term retention.

• Set clear objectives tied to business goals, whether that’s revenue targets, customer activation rates, or pipeline generation
• Weigh trade-offs between short-term wins and long-term growth. Should the focus be on user adoption now, or is revenue the key metric?
• Link these objectives back to your GTM strategy and the key bets you’re making with this launch

Clarify roles and responsibilities

A launch quickly derails when teams aren’t clear on who owns what. Assign ownership early: who is responsible for sales enablement, pricing approvals, customer support training, and marketing execution? When ownership is clear, accountability follows.

• As a PMM, act as a program manager, not just a project manager
• Identify a Directly Responsible Individual (DRI) for each workstream and ensure they have the authority and capacity to execute
• Work with leadership to ensure the launch is a priority for each DRI, not just another task on their list
• Set clear expectations: each DRI owns their workstream, communicates progress up/down/across, and manages their project plan
• Rather than micromanaging, empower all DRIs to take responsibility

Create urgency and sustained momentum

Without urgency, launches stall. Set milestones leading up to launch, communicate progress frequently, and remove blockers early. Build internal excitement, celebrate wins along the way, and maintain post-launch energy by reinforcing the impact of the launch.

• Plan internal communications as carefully as external ones. A product launch is also a change management initiative; teams need to understand what’s coming, why it matters, and how it affects them
• Set clear expectations across the business, outlining what to expect during the launch and what role each team plays in making it successful
• Ensure department leaders are aligned and communicating the right message, so the entire company moves in sync
• Use execs to drive alignment: when they reinforce priorities, teams listen

Proactively manage dependencies

Product launches involve multiple moving parts across teams. Mapping dependencies early prevents last-minute chaos. One of the most critical aspects of program management is forcing teams to talk to each other.

• Encourage workstream DRIs to take ownership of their needs rather than waiting for others to anticipate blockers
• Set up a weekly sync where DRIs align on interdependencies, track them in the project plan, and flag concerns before they escalate
• Reinforce that asking for help or resources early is a strength, not a weakness. Transparency is key (and expected)

Schedule pre-mortems and post-mortems

Expect iterations; don’t be surprised by them. When you make iteration part of the plan, you’ll get better feedback without last-minute chaos.

• Schedule pre-mortems before launch to anticipate roadblocks, identify risks, and ensure teams are aligned on what success looks like
• After launch, hold post-mortems to gather sales insights, analyze customer feedback, and assess real-world performance
• Build in time to refine positioning, update enablement materials, and tweak the launch strategy based on learnings

Sustaining momentum after launch

Too many teams treat launch as the finish line when, in reality, it’s just the start.

• Track adoption metrics and customer feedback to identify areas for improvement
• Reinforce sales enablement with updated objection handling and refined messaging
• Keep the product integrated into marketing and sales motions to sustain awareness and pipeline growth
• Ensure product and customer success teams are working together, not just for adoption, but to help users thrive

If you treat launch day as the end, you’ll miss the real opportunity: long-term impact and sustained success.

Keeping momentum after launch separates the products that thrive from the ones that fade…. and how you execute post-launch is what ultimately determines your long-term success.

Bringing it all together

Treating a product launch as just a marketing event is a mistake.

A great product launch is a business initiative, not just a marketing campaign.

The best PMMs don’t just market launches; they lead them.

A launch isn’t successful when you ship, it’s successful when your product wins.

Thanks for reading! Let me know what you thought – find me on Twitter and LinkedIn.

P.S: If you enjoyed this post, will you share Building Momentum with your network?

The post The big misconception about product launches appeared first on Building Momentum.

I’ve been thinking about this a lot recently, due to my work and things my friends are also working on. I’ve helped create, rollout, and scale second and third products.

There definitely is a right and wrong way to build your second product. I actually think that in an ideal world, your second product should be a product you acquire, rather than build yourself – I’ll explain why later.

But first, let’s look at the usual way a second product comes about, and then how I think it should be done.

A typical second product story

I’m talking about a second actual product, not just a major feature of an existing product. A second product that should have it’s own dedicated product/engineering teams and a separate go-to-market.

What usually happens is this: your founder or someone in the exec team spots an adjacent problem that your company should solve. They either suggest – or dictate – that the second product is something that must be done – it’s critical to the future success of the business and NOW is the time to branch out, to build upon the traction you’re experiencing.

So it’s assigned to a product manager, with an exec sponsor. The PM goes away and starts thinking about the product.

As most PMs are prone to do, they’re closer to the delivery of features than the development of a proposition. So they come back with a plan to build the thing and get it going. The exec sponsor goes back and gets the green light – this is a huge money-making opportunity!

Maybe a product marketer gets involved. As we are prone to do, we ask hard questions about the customer, the opportunity, the proposition.

“We just need to build the thing!” they say. “We’ll find customers who care about this when we’ve built it!”

Dutifully, the PMM carries on, supporting the proposition development and planning the GTM. Launch comes, and… the reaction isn’t quite as hoped.

“But the first, original product is a success! How could this happen?”

Well, it was different back then.

• The founder started the company probably because they experienced the pain firsthand
• They had unique wisdom that gave them shortcuts to pinpoint pains and develop the proposition
• They were probably working closely with customers to develop the product from day 1
• The gap between the interpretation of the problem and the execution was more narrow – maybe a CEO, a CTO, and a few engineers.

Now – with best intentions – the second product is a bit more difficult.

• The founder may not have experienced the second problem as deeply as the first problem
• They may not have as deep unique insight, or it’s based on outdated context
• Survivorship bias means the founder underestimates the amount of constant iteration and rethinking they did the first time round
• The interpretation gap is wider – understanding and context has to filter through a PM, an exec sponsor, and a founder both ways

So, through no fault of their own, the founders expectations and the reality of what the PM can deliver is out of sync. That misalignment – of the market opportunity, of the requirements to compete, of the deep context to be understood – is painful.

Building a second product (the right way)

Here’s how I think – and have seen – second products built the right way.

Firstly, an adjacent problem is identified from several sources including existing customer interviews, sales conversations, and the objective synthesization of market opportunities from the exec team.

It’s handed to a product marketer and product manager, who – as a team – are tasked with validating and quantifying the opportunity. A research sprint is undertaken: desk research for current solutions to the problem, existing customer interviews, and new market interviews too.

A business case is developed, detailing customer segments, the market landscape, and an initial draft of a competitive proposition. Opportunities are highlighted: what could the first next step be? What customer segment would make an easy first target? Where are the underserved needs in the market today?

This is reviewed and receives sign-off, empowering the product team to start building an MVP. At the same time, the product marketer works to iterate the go-to-market package: drafting and testing messaging, researching a distribution strategy, working with a sales/marketing ‘tiger team’ to start defining the GTM.

In constant contact with interested customers and prospects, the product team begin to ship product that’s tested by real hands. Quick feedback loops enable users to provide feedback on workflows and screens that the engineering team can pick up to improve without a longwinded selection process.

At some point, momentum starts snowballing – users begin to love it, issues decrease, and your initial sales/marketing results are exceeding expectations. Product/market fit has been achieved.

Of course, it never really happens like this – there’s usually a few more hiccups along the road. But hopefully you’ll recognise some of the smoothness, the natural pull and eagerness from the market, and the ‘start with the customer’ approach.

Or, could you acquire a product?

I think that, more than ever, acquiring a company as your ‘second product’ makes a ton of sense.

Not only are you acquiring the technology – which, with a well-resourced plan, can be integrated into your own stack – but you’re acquiring customers. They already had the pain, and they searched for a solution to solve it.

You’re acquiring expertise. Those founders, the product managers, the engineers all have more context on the customer problem to be solved than your team can learn quickly – even though the problem is adjacent.

And you’re buying experience. What worked? What didn’t work? What does the market want, need, what are competitors doing, how does selling and marketing work best?

These shortcuts – hopefully – would make it easier to build momentum with a second product. You can learn where the overlap are between your existing product customer base and your acquired base so you can figure out the cross-sell motion. You’ve already got revenue, a baseline for growth, and tactical plans to start optimizing from.

Regardless, look for focus + confidence

As longtime Building Momentum readers will know, momentum is the output of confidence + focus. If you have focus (in the customer, the problem, the product) and confidence (that reality will match expectations) – you will build momentum.

Whether you’re acquiring your second product, aspiring to build it “the right way”, or struggling through a mess, finding ways to increase focus and confidence will serve you well.

Thanks for reading! Let me know what you thought – find me on Twitter and LinkedIn.

P.S: If you enjoyed this post, will you share Building Momentum with your network?

The post The Second Product Pitfall appeared first on Building Momentum.

Getting to product/market fit will make or break your business. Defined as the point where your product or service satisfies the needs and wants of a particular market, it’s tricky to achieve, difficult to measure, and doesn’t actually mean you’re more likely to be successful.

But, as with everything, it’s a proxy for being on the right track – for building momentum.

There are a few signs that you’ve achieved product/market fit:

1. Strong demand – a “pull” from the market
2. High retention and engagement
3. Positive word-of-mouth – customers advocate for you without prompt
4. High Net Promoter Score (NPS)
5. The “Sean Ellis Question” – 40% or more customers say they would be disappointed if your product/service was not available

There’s a ton of content out there on common product/market fit mistakes – things like focusing too much on features, building in a vacuum of customer insight, and building a proposition that people like, but nobody will pay for.

But what’s not shared often are the human mistakes that we can make on the journey to find product-market fit. I’ve seen all of these mistakes happen, multiple times, over the last ~12 years – and made most of them too.

If you’re at an early-stage startup, or building a new product from 0-1, keep these in mind.

Product or market or fit evolves organically – without a clear decision

Let’s take an example from my experience: a small, HR tech startup developing diversity recruitment technology for enterprise businesses.

In my first few weeks, we quickly discovered that our target customer – Head of D&I roles – were super interested in the product, but didn’t have the budget or authority to implement within their business. But who did? A role in the recruiting business – a Head of Graduate Recruitment.

We talked about this a lot internally and reviewed all of the feedback we had – from sales notes to customer feedback and opinions from our advisors.

But rather than make a clear decision and communicate it internally to announce that we had learnt something new, and we’d be switching our approach, we let it linger. We didn’t want to burn the work we’d already done, and in hindsight we fell into the sunk cost fallacy trap.

By trying to keep our options open, we’d actually made an own-goal.

We weren’t all aligned on who our customer was. Product managers were focusing on our new target, but Sales still wanted to explore opportunities with existing D&I relationships. This meant feedback was fuzzy and inconsistent – we were getting mixed messages, and not enough insight into our evolved market.

And, at the middle of it stood me and the CEO, trying to pacify both sides and find common ground to let us move forward. In hindsight, the decision was the CEOs to make – their lack of declaring a way forward and asking teams to ‘disagree and commit’ was a mistake.

Panicking, and implementing a “spray-and-pray” approach

One of the most dangerous things I think you can do in pre-PMF stages (and, you know anytime!) is say ‘we want to sell the product to anyone!’

Being something for everyone doesn’t work when you’re scaling – so why would it work when you’re just getting started?

There usually comes a time when you’re exploring PMF and things don’t seem to be going well. You’re not getting the right feedback, sales aren’t happening, or maybe your funding is running dry.

It’s SO TEMPTING to say fuck it, let’s just try selling it to anyone. Of course, it’s never said like that. It’s usually positioned as ‘let’s explore adjacent markets’… or someone says ‘I have a potential call with… is it worth it?’.

You’ll also see the flipside happen too: your product becomes a shapeshifter. One minute, it’s an invoicing solution for SaaS businesses. The next, it’s a fully-featured billing platform. To another prospect, it’s a headless API for subscription management.

For sales reps, especially those who are used to selling agency or retainer services, the discovery phase becomes less about disqualification (remember, more important than qualification!) – and more about understanding what the customer needs to sell a custom solution.

Bad Idea. Without a single, defined product proposition to qualify prospects against, it becomes so difficult to understand what is and isn’t working.

Lack of structured feedback process

PMF is a giant experiment, so why don’t you treat it like one?

Willy-nilly, haphazard reactions aren’t sustainable. I’ve seen this happen because people think they’re being agile, hoping to learn quicker.

But what actually happens, just like all the above, is an own-goal. Your approach splits. Your market becomes disjointed with the product. The product moves away from the market. Harder to get consistent feedback. Harder to make decisions.

At a previous company, we did treat PMF as a hypothesis. We had structured conversations about our target ICP, about the lessons we were learning, and experimented with propositions together. And it worked.

Here’s what I’d recommend:

• Use an experiment canvas to define what you’re looking for
• Revisit regularly to discuss findings and measure against expectations
• If it’s not working, use a structured approach to deducing whether it’s the strategy or the execution
• Share feedback without bias, as much as possible

I’ve also been in the position where there was no structured approach to feedback, and everything was based on gut-feel and the most recent sales conversations. It’s not fun. The pressure is on, and you’re stuck in a vicious and cruel circle of pain. Avoid.

Remember, PMF is iterative

Try as we might, it’s probably not going to happen overnight. Your journey to product/market fit is just that – a journey.

Enjoy the journey, navigate the product/market fit map, and try not to take too many wrong turns.

Good luck!

Thanks for reading! Let me know what you thought – find me on Twitter and LinkedIn.

P.S: If you enjoyed this post, will you share Building Momentum with your network?

The post 3 mistakes to avoid on your product/market fit journey appeared first on Building Momentum.

SPONSORED

Capture customer feedback at scale with Vouch

In this 1 minute video, powered by Vouch, James shares 3 ways customer feedback can help your business grow faster. Watch it here.

Vouch is a video collection platform, perfect for customer feedback. Create fast feedback loops that collect customer insights 24/7. Just add your questions and share the link through your campaigns, automation flows or website. 

Try Vouch for free today

Think about the products and tools you use at work and in your personal life.

Everything you use is designed to help you accomplish a task in a particular way. A job-to-be-done, with success criteria. Therefore, nothing in life is purely functional. Everything is functional, plus something else.

• Your shower gel might rid you of dirt – and also have a nice smell to make your shower more enjoyable.
• The sofa you sit on is comfortable to sit on – but is also a visible signifier of your design choices (budget notwithstanding)
• The laptop or phone you’re using right now? An all-in-one lifestyle device to help you live life the way you want to
• The CRM your sales team use is not just a record-tracking tool, it’s a decision-making platform for business growth

All of the product design choices and all of the marketing, sales, positioning, messaging decisions were consciously defined to not just be functional, but to help you achieve the job and meet the success criteria.

Now think about the software you market or sell.

Are you just selling task completion – or are you actually selling more than that? And if you are… what would change if you decided to do so consciously?

We build software, but sell outcomes

We shouldn’t be marketing or selling software. We should be selling value, an outcome that your customer wants to attain that:

1. Is useful
2. Is worth the effort (cost, time, energy)
3. Is a priority for them

Sometimes this value is clearly messaged, linking the features of your product through benefits to value. I call this a ‘value nugget‘.

Sometimes, that value ISN’T communicated well – and it becomes muddy, confusing, damaging.

Without a clear understanding of the value your customers desire – and why – you’ll find it harder to sell and market. Functional messaging is obtuse: a blunt and binary approach.

But when you sell value, you create more. The whole of the value is greater than the sum of its parts. You can charge more. Loyalty and satisfaction goes up. You sell more, faster.

And just like the products you use in your own life, customers buy things to complete jobs that will meet their success criteria. Sometimes that will be obvious: more revenue.

But actually, I think more often the success criteria customers actually make purchase decisions on is not obvious. Sometimes, a particular product is bought just because it’s the only one the data protection team will sign off on, even if it’s not best-in-class. Or because it’s the one with the best brand recognition. In an example I use often, Salesforce isn’t bought because it’s ‘easy to use’, but because it’s an industry standard, which means a faster sales rep ramp time.

We sell software as a service, but we actually offer an experience

If you work at a SaaS company, I’ll bet you money (tip jar here!) that you’re doing all of these already:

• Creating content and campaigns that speak not just to your product’s capabilities, but to the broader concerns your customer has in their role
• Creating content marketing not just about your core product, but how to get better results in your industry overall
• Training customers with a customer success team, who give support on how to do their jobs better and achieve better outcomes
• Building product features that helps customers solve adjacent problems and achieve sub-jobs

SaaS is more than software.

SaaS now encompasses the whole experience that we deliver to help customers find, buy, use, and stay engaged with us.

But we don’t consciously acknowledge this. We still think we’re selling and supporting software through various components of our business.

If anything, we might put together a buyer journey map which looks at the holistic experience a customer has with our business.

But to take it further, we can create a job-to-be-done map that addresses not just the tasks a customer completes with our product, but looks at the broader process they follow to get something done.

This can then provide the evidence and inspiration to power rest of your ‘Outcomes-as-an-Experience’ strategy:

• Product ideas to support adjacent problems and sub-tasks
• Marketing content on the broader challenges to attract, educate, and retain customers
• Ideas to build customer success and consulting services that support overall completion of the job, not just the tasks

Warning: don’t rely on internal assumptions

It’s dangerous to rely on your own internal assumptions. Everyone is too close to the product and it’s specific capabilities. Everyone is too invested in its success. Whilst you might have done the job before, you’re likely more mature than the majority of your market.

It really is as simple as talking to customers directly to understand what they want to achieve and how. Just keep an open mind, ask questions, and you’ll learn exactly what you need to take your business to the next level.

Thanks for reading! Let me know what you thought – find me on Twitter and LinkedIn.

P.S: If you enjoyed this post, will you share Building Momentum with your network?

The post SaaS? More like Outcomes-as-an-Experience appeared first on Building Momentum.

Often, product managers and product designers don’t really understand product marketing. Maybe we’re there to just add some sparkle on the feature messaging.

But I’ve found the Double Diamond to be a helpful way to frame where PMM can add value to the product development process, pull out the specific inputs/outputs from each stage, and help others understand the role we play.

What is the Double Diamond?

Created by the UK’s Design Council in the mid 00s, the Double Diamond is a framework to show how, ideally, design happens. Each diamond is split into two halves, representing divergence-convergence.

The first diamond is all about discovering and then defining the problem. The second diamond is how you develop and deliver the solution.

Doing the right thing

The first diamond is how you make sure you’re solving the right problems.

Diverging, during the ‘discover‘ phase, is really about understanding user/market needs through research and insights. We want to look at the world from a pure, unbiased, unencumbered perspective to build a rich picture of user needs through a variety of sources, like:

• Market research
• Customer interviews
• User research
• Competitor insights
• Internal stakeholders
• Technology research

Product marketers, working with UX researchers or product managers, can provide a huge source of insights here with the bread-and-butter of our work.

After broadening the potential, it’s time to converge and define the problem that will be selected.

Having collected research and information, this stage is about creating structured insights that can be used to prioritize problems to be solved through a number of frames, like:

• What’s feasible?
• What problem matters most to our customers?
• Which aligns best with our business mission?
• Which helps us meet our business goals?

This is typically more the work of a product manager, but product marketers can still help by creating synthesised insights (like personas) and supporting prioritization work by representing the voice of the customer.

Doing the thing right

Once you’ve selected a problem opportunity to work on, the second diamond looks at how you solve the chosen problem in the right way.

The divergence phase, develop, is a collaboration between product management, product designers, and engineers. Here, develop might start by wireframing and prototyping potential solutions, refining and validating.

Product marketers can help this part of the process by engaging in ideation workshops and again, representing customers.

This can take a lot of trial and error until the team begin executing on a specific solution to deliver.

With iteration in mind, you might not actually be building code, but perhaps some other indication of the concept: prototypes, landing pages, or ‘wizard-of-oz’ solutions to validate with your customers.

This is often a play between PMs and Engineering until a release plan is developed. Product marketers might get involved in planning and running a beta phase, or maybe planning and executing a full go-to-market launch.

It’s an iterative process

The double diamond is not a linear approach.

It’s expected to be an iterative process, constantly evolving, circling back between stages to ensure that you’re ultimately going to be building the right thing in the right way that delivers value to your customers.

Thanks for reading! Let me know what you thought – find me on Twitter and LinkedIn.

P.S: If you enjoyed this post, will you share Building Momentum with your network?

The post Product marketing and the Double Diamond appeared first on Building Momentum.

The product<>sales dynamic is often fragile. Time and time again, I’ve seen these three issues at play:

1. Sales feel unable to influence product roadmaps. This can happen especially in companies that are very engineering- or product-led. Sales reps are talking to specific types of customers all day long. When that feedback is ignored, goodwill is lost.
2. Product don’t trust sales’ judgement. We’ve all heard it before: “We just need this one feature to win this deal!”. Because sales teams operate with smaller patterns (1-10 customers), their patterns aren’t conclusive enough to feed into problem-discovery.
3. Product ‘ships too slow’. Sales feel that product teams are taking too long and not delivering product improvements at the right velocity, whilst product teams feel they’re operating at the right pace.

These don’t just create animosity, but can snarl up time and attention – eventually leading to inertia.

Introducing a ‘statement of direction’ document

Whilst tackling the challenges above requires long-term dedication to building trust and working on the relationship, a statement of direction is a great initial deliverable to align both teams and start the conversation.

A statement of direction serves two purposes:

1. An internal alignment document to communicate the problem areas that the business will be investigating – giving sales the ability to talk confidently about future direction
2. An external document and presentation that captures the main themes for future product direction, enabling customers and prospects to buy into the future vision

They’re updated every 3-6 months and evolve as you learn more about your customer, market, and innovation opportunities.

What is a statement of direction?

A statement of direction is not a roadmap: it doesn’t cover the specific features that are being planned, or give estimated timelines. Instead, it describes the problem areas and innovation themes that the business is strategically investing in.

A statement of direction usually contains:

1. Vision: the world that you’re trying to create for your customers and the outcomes they’ll be able to achieve, including the barriers that prevent them from getting there. This is not an internal product vision.
2. Product investment themes: an overview of the key surface areas that impact the customer experience. These might be based around problems or intended outcomes.
   • A summary of why it’s important and what it means to your customer base
   • A breakdown of any recently-released features to prove your progress in each area
   • An explanation of your product shipping cadence
   • A brief overview of the direction for this theme, usually organized by next/future timelines. This allows you to communicate ambiguity for further-out opportunities, and present clarity for things that are more shaped.

It takes conversations to create a statement of direction, engaging sales, product, marketing, customer success, and other teams. First, you need to identify the product areas that matter to your customers – external-in, not internal-out. Then, you can align existing priorities and opportunities already in play before validating with other teams.

It’s important to also train teams on the statement of direction, and how to use it. It’s not promising timelines, prioritization, or specific deliverables. Instead, it’s communicating the mandate has business is strategically chosen, and the direction that customers are buying into.

Is everyone onboard?

Whilst you might think the primary objective of a statement of direction is to communicate externally, I think it’s much more powerful when used as a tool to align your business – specifically, product and sales – on what you’ll b2e building and the problems you’ll be solving for customers.

This helps to build focus and confidence… and as regular readers will know, focus + confidence = momentum.

Thanks for reading! Let me know what you thought – find me on Twitter and LinkedIn.

P.S: If you enjoyed this post, will you share Building Momentum with your network?

The post Aligning sales and product with a statement of direction appeared first on Building Momentum.

Announcing new features can be the bane of a product marketer’s work life.

Product can build something autonomously, let the PMM know when it’s going to be shipped, and expect it to be announced through the usual channels.

And, well, that’s probably fine. But it’s not great.

It’s an example of PMM as a conveyor belt team.

Teams can take many different approaches to feature launches. The most common in SaaS is based on Intercom’s feature prioritization matrix

And this is fine, but it lacks any real strategy. Deliverables are turned into tasks, checked off in a to-do manager for a feeling of satisfaction – but a lack of impact.

What if we reimagined how to ensure feature releases make a real impact on our business, our customers, and their outcomes?

The five A’s of successful feature releases

We all want our feature releases to have impact – ideally with the minimum work required. But to get there, we need to build new concepts to think about the intended outcomes, not just the planned work.

See what you think below – could you use these four concepts to get more efficient and effective feature launch results?

Audience

The audience you promote new features to probably has a bigger end-result on performance than whatever it is you’re actually shipping.

Just as with defining the ideal customer for your product, we need to niche down. Don’t just blast the email and show the in-app notification to all customers.

Instead, be selective: who needs to know about the feature?

For example:

• Customers that have shown interest or meet a particularly niche segment
• Show to all existing customers, only those who joined between specific dates, or only those with a specific registration date
• Send emails with different copy and action depending on the user persona

A good tip is to think about the anti-audience: what types of customers will NOT be interested in what you’re announcing?

Awareness

Every feature release checklist in the world has:

• Email
• In-app notification
• Social

… as standard for every top priority feature. But does it actually make sense to do these for every release? Probably not. We keep these in because we think it’s a good idea to make customers informed of new features, even if they’re not tied to their particular usecase or challenges. More product features is always a good thing, right?

I think it can do the opposite: too much noise trains your customers to ignore feature releases. In-app notifications get swiped away instantly without a second thought. And if they’re luckily enough to be opened in the first place, emails are skimmed and archived immediately.

Instead, think about how we can help customers become aware of new features at the right time.

For example:

• Show in-app notifications to customers when they take a particular in-app action (e.g. visit a new page, or click a specific button)
• Send behavioral emails when it makes sense, not just at a specific point in time because the functionality is now available

Always ask whether announcing the feature now will have the best impact, or if there’s a more timely approach.

Action

What’s the specific action we want customers to take with our feature release?

Tip: ‘Read the announcement blog post’ is never the best use of your customer’s attention.

Sometimes we’ll want to guide customers to enable a setting, setup a new feature from scratch, or convince their boss to purchase an add-on. Sometimes, it’s just an FYI – “there’s a new thing, thought ya might be interested.”

This largely depends on everything above – the audience, the channels you’re using to build awareness, and the affinity you’re chasing.

For top-tier customers, we wouldn’t send an email that asks an admin to just ‘switch on’ a feature that uses machine learning to do stuff. We’d use an explainer and ask for a meeting to be booked to showcase how the new functionality can lead to X% better outcomes.

Considering the most effective next step, and enabling teams across customer success, support, sales, and product is a surefire way to build an efficient customer/user journey.

Affinity

This is getting deep: what do we want customers to feel when we announce features?

A good exercise is to work with your customer success team and start with first principles. For each customer tier, what should their experience entail? What role do feature launches play in their evaluation, usage, and renewal/expansion decisions of your product?

For example:

• Top-tier customers are focused on processes and avoiding hiccups, so we shouldn’t announce new features to them autonomously. New releases should be batched up, and presented by a customer success manager who can tailor them to the client’s specific use case.
• Self-service, low-touch customers are mostly interested in ease of use for core capabilities, and improvements to these should be proactively promoted.
• Customers with the potential to expand need to feel confident in our product innovation velocity – let’s send them everything, as soon as it’s available.

This then allows you to execute more impactful launch strategies that contribute to a customer’s perception of your company.

Accountability

The holy grail of PMs and PMMs is to measure feature releases against business or customer outcomes, and iterate until those goals are achieved.

In reality, it’s very rare. It can take a lot to reorient a business around a different approach to building product, and it’s difficult to showcase incrementality (whether PMM work has had an improvement against the baseline, or not).

In the meantime, we can all start somewhere.

For certain features where it makes sense, we should guesstimate some goals that show whether our feature release met the specifics we’ve outlined above – plus any measurable business or customer outcomes.

For example, we might report on:

• Audience: How many targeted customers were successfully reached in the first four weeks of a feature release
• Awareness: How many customers engaged with feature release comms
• Action: How many customers took the intended action (e.g. activated a feature)
• Affinity: Positive/negative feedback via support and success teams
• Accountability: Whether business/customer outcomes have been met

Don’t wait for a full strategy: get started today

When I talk to product marketers, often the biggest barrier to more effective feature releases is waiting for a bigger strategy (either from their leadership, or their own to-do list).

But you don’t need to think through the whole strategy first. You don’t need to build the perfect matrix, think about the never-ending list of distribution and marketing channels at your potential disposal, or drag out sign-off from ten different stakeholders.

Just start with your next feature:

• What’s the best audience for this – and what’s the anti-audience?
• What channels make the most sense for this, and when would be best for customers to become aware?
• What’s the overall intended action, but what makes sense as the next step in the journey?
• What should our audience/customer segments think and feel about our product with this announcement?
• What makes sense to measure, both as a yardstick for the announcement performance and as a proxy for feature incrementality?

Spend a few minutes thinking about these, write the answers down, then build from there. Have fun!

Thanks for reading! Let me know what you thought – find me on Twitter and LinkedIn.

P.S: If you enjoyed this post, will you share Building Momentum with your network?

The post The 5 A’s of successful feature releases appeared first on Building Momentum.

I was a quasi-product manager for the activation and conversion experience at Kayako – everything from signing up for a free trial to the first payment was in my purview. This was pretty unusual: I was a product marketer with no product management experience.

Usually, product managers or growth marketers might have high-tech, data-driven ways of optimizing these experiences – but as a small team, we didn’t have data analysts, in-depth product tracking, or trained user researchers.

Instead, we relied on good ol’ research interviews, a couple of other tools, and an iterative mindset to go from low conversions to high growth. In this post, I’ll cover the main lessons that have stuck with me since then.

Before you go further, you might want to read From failed product launch to $2m ARR, where I talk about the challenges we faced as we turned a failed launch into growth momentum.

And of course, I’ll caveat by saying that these lessons were extremely relevant in our context at the time, and your mileage may vary.

The first-run experience is crucial

I highly doubt that your customer, when they sign up to your product free trial for the first time, goes in thinking “Wow, I can’t wait to get set up and configure my account!”

Most onboarding advice is focused on reducing your customer’s ‘time-to-value’, i.e. getting them to a point of success as quickly as possible. That might work well for some, but not for products that require a decent level of configuration.

At Kayako, our original experience was focused on setting up the account: adding an email address, inviting the team, and adding some rules. Customers ignored it, and it didn’t work.

Through interviews, we found that customers instead were still exploring whether they should commit time to evaluate the product any further. The first-run experience was not an evaluation: it was an evaluation as to whether they should evaluate.

With this insight, we moved away from focusing on ‘time to first value delivered’ and instead focused on ‘first value potential’.

As well as interviews, we used Fullstory to watch sessions of successful users in the product who converted. From here, we created a simple Trello board – what I now know is a basic job-to-be-done map! – that detailed the questions and tasks they would complete.

First, our customers needed to learn the product. Their goal was to understand what working in the product would feel like.

Unlocking this added so much value for us. It meant we could instead educate users on the value of Kayako, and showcase all our differentiated features in context of the problems they were facing.

As soon as someone signed up, we showed a two minute intro video, then we hit them again with three key points to drive the message home.

We added empty stages and dummy data that demonstrated the full range of capability, without requiring any setup. Our goal was to get to a place where users could see what working in the product was like from the moment they signed up.

Ongoing education

One of the most interesting things we found in our research, mainly through watching Fullstory sessions, was that most signups went straight to the admin area of the product.

Obviously, we hadn’t paid it any attention.

When we asked customers why, they said that they wanted to understand the product’s capabilities and features. But without seeing these in context, It was confusing, technical, and off-putting.

Could we convince them to go elsewhere? Absolutely not.

So we took the education to them instead.

Empty states

Empty states are placeholders, shown when there’s no data to display to the user. Rather than have empty space, we showed fun illustrations and added context to educate users on what would usually appear there.

Here’s a beautiful example from Shopify. When a customer on a free trial is browsing around the admin area, they see an eye-catching illustration with a great explainer of the benefit they can gain using this feature.

Dummy data

We needed customers to imagine what working in the product would really feel like. Random and incomplete juxtapositions of test data wouldn’t cut it.

We created our own fictional world, Brewfictus: a coffee equipment and supply retailer that had multiple customers and storylines – all built to showcase our product features in a seamless, organic fashion.

We didn’t just throw any old copy up – we put thought into the vibe we wanted our customers to experience, as if they were actors playing our script. We also used the same contexts in our demos, videos and images on the website, and in design mockups.

Did this help impact conversion? Not sure. But I hope it showed that we cared.

Nudge users to easy next actions

We found our customers would get distracted, clicking out of our guided tours to explore on their own, or just dropping off the session altogether.

This meant we struggled to get users to go through the entire experience in one sitting. And that’s fine: life happens.

We used our basic JTBD map from above to track the key events a user had completed, and then followed up with behavioral nurture emails. Rather than focus on the broad progress a user had still to make, we used urgency and simple messages to encourage users to complete one simple next step.

With a 14 day trial we could email users almost every day and always provide an actionable, low-effort next step.

Bringing it all together

Combined with our educational first-run experience, our context-sharing dummy data and empty states, and behavioral email nudges, we saw successful conversions increase within our trial period.

Even without dedicated data analysts, we were able to listen to our customers, understand what they were trying to accomplish, and build an onboarding experience around their needs.

Thanks for reading! Let me know what you thought – find me on Twitter and LinkedIn.

P.S: If you enjoyed this post, will you share Building Momentum with your network?

The post Building an onboarding experience around your customers, not your product appeared first on Building Momentum.

How much effort are you wasting internally based on seemingly smart — but unvalidated — internal ideas?

Over the last few years, thanks to the efforts of John Cutler, Theresa Torres and others, tech companies have embraced a new product management paradigm of opportunities, bets, iteration, and slices.

The intention behind this new world is to move away from big bang releases and instead ship value across the whole chain in iterative chunks. This requires continuous customer development, using the opportunity tree framework, building job-to-be-done maps, and generally being more receptive to a more fluid, less structured flow from insights to development to feedback.

Moving from internal to external opportunity generation

The goal is to move away from inward-facing insights and instead move to better understand and build for your customers. This means less off-the-cuff ideas, no more chasing competitor features just for “parity”, and the end of the HiPPO approach to product management.

And when it’s done well, teams should see increases in adoption, satisfaction, revenue, and speedier time-to-market.

Continuous customer development is one of the most exciting but underutilised tools in the product manager/product marketing/UX research toolkit.

Continually listening to the market and building a better understanding of customer needs can only be a good thing. From here, prioritizing those opportunities on their potential impact against the size of the “bet” and building only the minimum to increase confidence should mean we build resilient insight to feedback workflows.

The problem is that it’s so easy for us to justify building new features based purely on internal ideas, sizing them as small bets and foregoing customer validation because of overconfidence in our internal worldview.

Like in the TikTok above, we put the whole business value chain into motion. This doesn’t just waste time and money, but it’s distracting. Not only are there missed opportunity costs (from either building the thing right, or building the right thing instead), but it breaks down trust across teams. And as regular readers will know, confidence is a crucial part of the momentum equation.

Building an insight-driven product process

So how do we overcome the strong (and in some cases, overbearing) pull to build based on internal gut instincts?

Let’s use the “momentum equation” (Focus + Confidence = Momentum).

Focusing on customers and their jobs to be done

We need to build focus in the customers and opportunities we prioritize. This means having a really deep understanding of who our customers are, their jobs/pains/gains/triggers, and the common jobs they look to solve.

In practice, this means a consistent and structured approach to customer development. It’s not enough to do a positioning process with interviews, and then forget about researching the market ever again. You need to supplement projects with ongoing customer research. This might be a regular cadence of market research interviews for broad insights, as well as win/loss interviews for more tactical feedback.

We also need to use positioning as strategy, by detailing the value our customers desire and directing product efforts to better deliver those values.

I always recommend building a jobs-to-be-done map of your customers core jobs, allowing you to understand your product in context of your customers goal. You can also use JTBD maps to identify opportunities, by measuring satisfaction versus importance at every step.

Finally, opportunity trees are still relatively rare in practice, although the theory is solid. By focusing on the outcome and working backwards to identify different potential solutions (whether through product, service, or other methods), we can identify more innovative, out-of-the-box ideas with greater impact at lower cost.

Validate opportunities before (and during) development

Determining how much confidence your teams need before building something can be tricky.

But you know what’s easier to gauge? The inverse: how much work they would feel comfortable throwing away if a feature wasn’t working out.

Part of the new paradigm is to think of product development less as features, and more as bets. How much risk are you willing to take?

Luckily, we’re not making bets on a random roulette spin. We have the luxury of other confidence-building tools at our disposal: time, research, and iteration.

We can choose to spend more time considering a bet to gain all the required information – or we can move fast.

We could invest a lot of research effort to perfect the designs and ensure it met customer needs – or we could operate on low-fidelity signals to get things moving.

And we could build the full, end-to-end workflow – or just the first part to test demand before building the rest of it.

In practice, there are tons of ways that we can build confidence in the opportunities we build, from validating wireframes with friendly customers to operating a “wizard-of-oz” feature, and more.

The bigger challenge is to create a product and engineering team culture where iteration, delivering slices of value, and comfort making bets is accepted and lived.

Move at the same speed as your customers

One of the issues I’ve experienced is that it’s really easy for companies to think their customers are just as advanced as your team are, and therefore need all the bells and whistles you can dream of.

But your customers aren’t experts. They have a million other things going on that aren’t even vaguely related to your product or problem space. We can’t expect them to be as knowledgeable, foward-thinking, and visionary as your CEO, product team, or technologists.

The danger is that you move faster than your customers, and that alienates them. They lose confidence, and jump ship – while you’re left with a dodgy mix of simple and advanced product features.

But by using some of the ideas above, you’ll always be on the same page as your best customers, moving at the same speed. Great ideas will be validated quickly, while riskier bets will take longer to iterate from bad to great. You’ll ship product faster, customers will be happier, and you’ll have a solid foundation for aligning the rest of the business on what you’re building, and why.

Thanks for reading! Let me know what you thought – find me on Twitter and LinkedIn.

P.S: If you enjoyed this post, will you share Building Momentum with your network?

The post Focus and confidence in product appeared first on Building Momentum.

Today I want to walk you through one of my favorites, a Jobs To Be Done (JTBD) map.

A job map is a single document that details the steps your customers go through to ‘hire’ a product for a ‘job’ they need to do. I think every business needs one job map per customer persona, per product.

By breaking down their process to find, complete, and review their job, we can improve our understanding of the customer – and optimize our product, marketing, and sales to better meet their needs.

What is ‘jobs-to-be-done’?

Firstly, a recap. Jobs-to-be-done (JTBD) theory posits that people buy products and services to get a “job” done. Those jobs are mostly functional, however also have emotional and social components that also need to be fulfilled. Success comes from achieving the “job”, rather than gaining the tools to complete it.

You can read more about the JTBD methodology here, but watch Clayton Christensen in this primer:

Why use a job map?

Rather than user story maps, job maps don’t look at the individual actions that somebody takes in this journey, like clicks or searches, but instead look at the macro stages and micro-tasks that someone will do in their search to be successful.

Traditionally they have a lot of value in product management and can provide a foundation for the product discovery process. But I like to use them for two reasons: they’re really simple to communicate, and they base your product in the customers world, not yours.

I believe that everyone in a business, from backoffice teams to sales and marketing, should have knowledge of what your customers are trying to achieve. It’s logical that a culture that focuses on customer-first empathy will deliver maximum customer value.

Here’s a simple example of a Job Map.

The three blocks at the top detail the macro stages – I’ll come onto those in a second.

Underneath, you’ll also see the steps that the customer takes within each stage. For example, within the ‘Finding content’ stage the customer undertakes multiple steps. These steps are sometimes actions, but can also be decisions and considerations to be evaluated.

This map example also goes further to identify product opportunities. This works by surveying customers on the importance of each step, and how satisfied they are with their current ability to achieve it. By calculating Importance + (Importance – Satisfaction) to create an Opportunity score, we see where customers report their unmet needs, which could be opportunities for you to focus on.

JTBD map stages

To achieve the job, your customer will likely process through many or all of these stages.

It’s not as simple as just planning the job, doing the job, reviewing the job. There may be many more decisions, considerations, and inputs required to determine how the job should be done, what success looks like, or even if they’re ready to do it in the first place.

Again, many of these stages will take place, but maybe not all. You can simplify this by focusing just on the beginning, middle, and end of the job.

You can also dig deeper into your JTBD map by adding more levels. For example, each macro stage in your map may one or more jobs within it.

Linking JTBD stages to your product offering

In this table below, you can see how companies can improve their product offering by better meeting customer needs at each stage. This might be anything from offering simpler planning, to making set-up easier, or improving monitoring.

Communicating JTBD Maps

Job maps provide a single document that help everyone understand what a customer is trying to achieve and the stages they move through.

It’s a great basis for a really visual workflow explainer. Below is an example I’ve used before to show how visual it can be.

In the example, you’ll see:

• Macro stages along the job
• Activities at each stage
• Workflow elements to show the cycles and paths that take place in the process

They’ve also included what a customer is thinking and feeling at each stage. Again, this is great for bringing more empathy into your business. Detailing emotions your customer feels can also create more product opportunities for delight, as opposed to the cold, hard facts of the Opportunity/Importance/Satisfaction maths above.

Start your JTBD map journey

Realistically, you’re not likely to have user researchers available to spend time building this out. So let’s bring it back to basics.

To start building your JTBD map, ask a few people with domain or customer experience to put together their thoughts individually, before bringing together and talking it through.

Within a two hour workshop, you can have a good, solid draft of an initial JTBD map. From here, you’ll be able to measure your confidence at each stage – what do we have evidence for, and what may be based purely on assumptions?

With this information, you can go to customers and friendly people in the market to validate in casual conversations. You can iterate as you learn more.

An ideal scenario would be hiring a user researcher to carry out interviews, ethnographic research, and more to develop a JTBD map without organizational influence — helping develop a more pure understanding of your customers.

But for now, build your JTBD map, validate it, and socialize amongst your teams. Bring customer empathy into more conversations, and start identifying opportunities to better meet customer needs, delight customers, and optimize your business.

The post Why you need a jobs-to-be-done map appeared first on Building Momentum.

A great lead comes in: a real household name, with money to spend. They get through your SDR team qualification with ease. The AE’s discovery call goes swimmingly. The demo is great. And then they ask one single question that threatens to derail the entire conversation.

Prospect: “Do you have [feature]?”

AE: “No, but it’s on our roadmap.”

Prospect: “Do you know when it will be available?”

AE: “No. I can check with our team and get back to you.”

And the opportunity disappears, never to be seen again.

Why does this happen?

It’s not because you don’t have the feature available right now.

It’s not because your sales rep doesn’t know what the feature will be available. Usually, it’s an “nice-to-have” compared to the main product anyway.

This phenomenon happens when the sales rep doesn’t understand what the prospect expects the feature to resolve, and what benefit they are attempting to realize from it.

Without this knowledge it’s difficult to overcome objections, like re-prioritizing the importance the overall solution. This trough of momentum makes it difficult to build the urgency needed to move the deal forward.

To overcome, reps need confidence in their understanding of the customer and their problems. This confidence enables them to set expectations, dig deeper with questioning, and move the issue forward.

Usually, this skill comes from reps with domain knowledge: those who’ve done the work before or have intimate knowledge of the workflows involved. SaaS businesses with small teams, or those that are scaling rapidly, will find it harder to educate their team well enough to handle feature objections.

And then (even more annoyingly) you’re missing out on the rich and valuable information to feed back from the sales process to the product team. It makes it harder to gain mid-funnel feedback that could impact product prioritization, and unlock a lot more sales.

So how can you empower sales reps with the information and tactics they need to overcome these objections and push the opportunity forward?

Overcoming feature objections

Luckily, reps can maneuver around these conversations with a little help from the basic roadmap information you may already have.

Splitting your roadmap into ‘landing shortly’, ‘near term’, and ‘planned’ timelines helps your team set those relative expectations with prospects and have more productive conversations.

Educate your team on the problems to be solved

One prerequisite to overcoming objections is to give sales and success teams enough information, without overloading them on the technical details.

There are many different ways to align product, marketing, and sales, but I’d recommend the Jobs To Be Done methodology.

You can read more about the JTBD methodology here, but watch Clayton Christensen in this primer:

JTBD can quickly become imperious for customer-facing teams, but you can use the core concepts to help them understand what customers and users are trying to achieve.

There are five key components of a ‘job’ to be achieved:

1. Who: Who is the executor of the job, who will be overcoming the problem?

2. What: What’s the objective that the job executor wants to achieve?

3. How: What is the process the job executor will follow to achieve the objective?

4. Why: What are the intended outcomes that indicate success from completing the job?

5. When/where: What contextual factors matter in this scenario?

Using this framework when communicating the problems under investigation and features to be launched helps sales teams ground product development in a story they can internalize and retell.

Set expectations, question, move forward

Armed with that knowledge, give your team the tactics to overcome those objections.

Here are some template approaches to ensure your roadmap helps, and doesn’t hinder, your team’s sales conversations.

Landing shortly

These are features that are currently under planning and development that your product team have 95% confidence will be implemented within the next few months. The designs are set, the technical build is estimated, and we know what problem it’s intended to solve.

Set expectations:

• This is something our product team is working on right now, it’s slated to be available this quarter.

• We’re expecting this to [solve problem] by [method].

Question them:

• How would you use that?

• Is it a feature you’ve used before? How do you achieve it today?

• How is that met by the other solutions you’re evaluating?

Move them forward:

• Ask if they would be interested in seeing the mockups, or getting early-access when it’s available

Near-term

These are features that you expect to deliver next quarter: they may be loosely scoped, but the opportunity exists to get information that will validate your problem/product assumptions.

Set expectations:

• We’re planning to start on this in the next few months for it to be available next quarter.

• So far, we understand the problem to be solved is [explain problem].

Question them:

• How would you use this feature?

• How will that impact your business and workflow?

• What problem would it solve for you?

• What benefit do you expect to realize from this, and why?

• Is it a deal-breaker to moving forward with our solution shortly?

Move forward:

• Take notes to understand their problem and share with the product team, to both provide additional validation and see whether the planned features will meet their needs

• Dial up the urgency and the pain their other problems are causing, that can be solved instantly with your solution today

Planned

Planned items are in the proposal and ideation stage. Set those customer expectations as such, and deep-dive for details on how customers would use these features. These situations are helpful for impacting development prioritization when there’s a dollar amount available to be indicative of future opportunities.

Set the expectation:

• I know it’s something our product team are evaluating this right now, but need more information on how to best solve this.

• So far, we’re expecting to help customers [solve broad problem area] and achieve [result].

Question them:

• How would you use this feature?

• How will that impact your business and workflow?

• How do you do this today?

• What problem will it solve for you?

• How do you achieve the same outcome today?

• Is the capability a deal-breaker for this type of solution?

• What’s the driving force behind this requirement?

Move forward:

• If their requirements are complex, confirm by email to make sure there’s no misunderstanding

• Explain that the feedback will really help the product direction, and ask if they’ll be open to contact by the product team

• If the deal isn’t a requirement to moving forward, explain how getting onboard now is an opportunity to be involved in the product design and beta process and ensure their needs are taken into account

Avoid saying no and ensure the feedback loop is closed

It’s too easy to say no, shutting down the conversation.

If you can, attempt to turn it back round to the features you do have  by re-prioritizing the problems you can solve.

But taking the time to understand requirements and feed that insight back helps product teams to build solutions that accurately meet the needs of your prospects and customers.

Taking note of the problems and features that prospects are interested in, even if the feature delivery is some time away, can also help with re-engaging in the future.

Thanks for reading! Let’s connect on Twitter and LinkedIn, and let me know what you thought.

If you found this post helpful, will you share it with your network?

The post Overcoming product roadmap sales objections appeared first on Building Momentum.