image_pdfimage_print

Nobody’s upselling? There’s a practical answer!

“The final sales problem is that nobody is upselling. “Many AEs don’t want to call their old clients and upsell them,” says Harris. “They hate it. They can’t stand it. They’re afraid they’re going to get sucker punched with a, ‘Oh I really love you guys, but this thing is broken. Can you help me fix it?’” https://lnkd.in/bqEWBBN … (Richard Harris AA-ISP’s TOP 25 Most Influential Inside Sales Professionals in 2015.)

That “thing is broken” problem Richard Harris raises in the quote above is a very real issue, which I’ve come across very recently. There is an answer, which unites sales and marketing as a team. It’s about creating practical customer-centric content that directly helps existing clients solve the “thing” that is broken.

For example in my last role at Causeway there were plenty of existing clients in our CRM, and which our accounts execs had a relationship with we could upsell to. Our CEO Phil reminded us all at an ‘offside’ at Stoke Park (where they filmed Goldfinger) that ‘farming your patch’ (upselling to existing customers) was the way to pick up most sales.

Farm Your Patch? Click the pic for my piece ‘Growth hacking within the enterprise – a simple, effective exercise!’

What I realised was there was an opportunity especially in Telematics to better upsell (subject to testing) by creating how-to type content that helped existing clients get a better ROI from their existing investment. One tactic to help this happen efficiently is to proactively gather feedback from clients as part of account management. As from experience part of the connected problem is that each customer thinks their issues with your product is entirely specific to them. And in turn account execs are not surprisingly put off from asking about an existing client’s problems in this context. Again there is an upside. The more you know about the specifics the more you can map out more general content for the top of the pipeline which highlights mistakes than even the best industry players might be making,

I was also helped and inspired in this respect by David Lennon at LinkedIn, who directed me to a case study (pdf, 2mb) from VistaVu which produces business management software for the oil industry which came up with a problem solving approach to lead generation – focusing on common operational mistakes:

“The company leveraged a thought provoking and unconventional advertisement with the heading “The 7 Deadly Sins of Oilfield Services Companies,” aimed at intriguing readers by providing a special report on common, yet costly, operational mistakes that even well-run companies can make.

“Within one week, the Display Ads campaign generated four to five times more leads than with any other online display advertising campaign across any network, on any site for VistaVu. Of the 20 new leads received, 19 were qualified for the sales team to pursue. Overall campaign cost per lead was also one-fifth of the cost that VistaVu typically spends for marketing qualified leads.

“In addition, the lead conversion rate was 2.4 times better (18.2%) than its benchmark with other online trade media display advertising. What’s more, VistaVu’s cost per lead (CPL) was approximately 75% lower when compared to its average CPL with other online advertising channels.”

So now you have two integrated content approaches to both generating new leads, and upselling to existing customers, that focuses on generic problems for new leads and specific ROI problems with your solution with existing clients. But back to the original point of this post, upselling by solving existing customer problems. How do you go about that?

If you want to find out my tailored suggestion on how to go about that for your business drop me a line below. I’m happy to chat!

Help for your business?

Fields marked with an * are required

Your MVP should so just 1 thing

Minimum Viable Products (MVPs) are tricky:

  • How “minimal” should yours be?
  • What does “viable” mean?
  • How do you keep it simple, without ruining your reputation?

MVPs only need to only do one thing. To understand that one thing, you want to understand the definition of MVP.

A video version of this blog post is available here.

MVP is the New Beta?

Remember when “betas” were a thing – as in, “we’re working on our beta version”, “we just launched our private beta”, etc.?

In the last few years, that term has been replaced with “MVP” – “we’re working on our MVP”, “we just launched our MVP”, etc.

This is where the confusion around MVPs stem from…

MVP is not the new beta.

The original definition of MVP from Frank Robinson is:

A version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.

In other words, your MVP is the version of your product with the highest ROI when you optimize for “validated learning.”

So how do you optimize for validated learning?

Test your “Riskiest Assumption”

For your business model to be successful, there are a number of assumptions that need to be true:

  • Customers know they have a problem
  • They want your help solving it
  • They will pay you to solve it
  • You can solve it
  • etc.

All of your assumptions can be prioritized in terms of “riskiness” where the assumptions that are most critical to the success of your startup, and/or are least likely to be true, are considered more “risky” than the other assumptions.

For example, “you can solve your customers’ problems” is critical to your startup’s success, but it’s very likely to be true (humans are natural problem solvers and since you’re a human, I’m confident you can solve your customers’ problems). On the other hand, “customers will pay you to solve the problem” is not only critical to your success, it’s also (unfortunately) less likely to be true – so you would consider that assumption more “risky” than the former.

Once you order your assumptions by their “riskiness”, to build an MVP, you build the simplest version of your product, that tests your riskiest assumption.

In other words, an MVP is:

A version of a product that allows a team to collect a maximum amount of validated learning of customers test their riskiest assumption with the least effort.

Notice how this definition changes the focus of an MVP from building a product, to running an experimentThat’s critical to understanding what an MVP is – remember that.

MVP or Not an MVP?

Use the following examples to test whether you understand what an MVP is…

Example 1: Explainer video

Dropbox famously gauged demand for their product via a demo video that, thanks to some video editing, demonstrated functionality they hadn’t built yet.

What do you think? MVP or not an MVP?

Let’s look at the definition again:

version of a product that allows a team to test their riskiest assumption with the least effort.

Does a demo video of functionality that doesn’t exist represent a:

  1. Version of a product that
  2. Tests the team’s riskiest assumption with the
  3. Least effort?

If Dropbox’s riskiest assumption was “people want a new service to sync/share files” and if it took less effort to edit video than it did to write code for the functionality that didn’t exist, then yesthis is an MVP!

As long as the riskiest assumption is being tested with the least effort, it’s an MVP.

If instead they’d built a simple version of their product (i.e. a pilot, a beta, etc.) and measured how many people used it everyday, the wouldn’t have been testing their riskiest assumption, and they wouldn’t have done it with the least amount of effort.

Example 2 – PowerPoint Demo

Let’s say you are going into a pitch meeting with a customer using a slide deck with mockups of your software. You’re not going to demo any functionality at all, you’re just going to talk about the problems you’ll solve while showing them some pictures, what do you think, MVP or not an MVP?

Recall the definition of MVP:

version of a product that allows a team to test their riskiest assumptionwith the least effort.

As long as you’re testing the riskiest assumption during that meeting (e.g. “customers will pay us to solve this problem”) with the least effort (a slide deck is less effort than even making a video), it’s an MVP.

Keep in mind that a slide deck is just like a video – minus fancy transitions. If a video meets your team’s criteria for an MVP, a slide deck might too – especially in B2B scenarios.

If on the other hand you went into that meeting hoping the customer would create an account on your platform and try it during the meeting – you’d be testing the wrong assumption, and you’d have done so with far more effort than a simple slide deck. A working prototype wouldn’t be an MVP.

Example 3 – Landing Page

If you imagine a landing page is just like a PowerPoint deck that you scroll through instead of click through, then you can already tell, a landing page can be an MVP as well.

Again, you want to use the least amount of effort to test your riskiest assumption – as long as you’re doing that, you’re building an MVP.

Anything more than that, and you’re getting closer to a “beta” product, than an experiment.

Example 4 – Facebook Advertisement

If you capture the essence of a landing page in a FB ad, with a title, image, description etc., then…what do you think: MVP or not an MVP?

What was that definition again?

version of a product that allows a team to test their riskiest assumptionwith the least effort.

So really, as long as you’re testing the riskiest assumption with the least amount of effort…you get the picture.

If we go back to the Dropbox example we can even see that depending on their riskiest assumption, they too could have used a Facebook ad to test this out.

If their riskiest assumption was, say, “people have problems syncing/sharing files” the Dropbox team may have been able to test that with a Facebook ad!

Example 5 – Simple App

A friend and I gave ourselves 24 hours to build a proof-of-concept app that would help people get to their appointments on time. It had basic GPS, traffic and calendar integration, rudimentary UI, and we only built it for Android.It got written-up Forbes and as a result, we were able to collect the email addresses of 3,000 people who wanted the iPhone version.

What do you think? MVP or not an MVP?

To know the answer, we have to look where we always look…our riskiest assumption.

If our riskiest assumption was genuinely, “We can build the app”, then it would have been an MVP. The truth is though, our riskiest assumption was, “People will pay for this app” and there was no way for us to test that with this app.

So, no, despite the app being simple, newsworthy, and popular…it wasn’t an MVP.

If it doesn’t test the riskiest assumption call it a beta/pilot/POC – just don’t call it an MVP

What’s your Riskiest Assumption?

Now that you know what your MVP needs to do, you just need to figure out your riskiest assumption so you can build one.

Good news! My post next week will tell you your riskiest assumption and the best MVP is to test it!

To Recap

  • MVP is not the new beta
  • Definition of MVP = (Say it with me…) The simplest version of a product that tests your riskiest assumption.
  • Before you build an MVP, you have to know your riskiest assumption.

Want More MVP Help?

This is the first of a four part-series on MVPs:

  1. (This one) What is an MVP?
  2. What Kind of MVP Should you Build?
  3. My 8 Favorite Tools for Building MVPs
  4. I’ll Fix your MVP: Send me your MVP and I’ll tell you what, if anything, to tweak to make it perfect.

Stay tuned for those.

Bonus: Want me to Review your MVP?

Leave a comment with a link to your landing page MVP and if it provides a good lesson for others to learn from, I’ll post a video review of what you’re doing well, and what you might consider changing.

The videos will be public so you and the rest of the Customer Development Labs community will learn from them which this is an ideal opportunity for startups who are:

  1. Confident in their landing page MVPs and want other startups to see it or
  2. Not confident in their landing page MVPs and want help fixing it.

Comments or Questions?

Please fire away!