Captain’s log, stardate 20220816

Benefits vs Deliverables

Writing proposals is hard if you don’t know what you’re doing.

And how are you supposed to know what to do?

It’s not like “proposal writing” is core curriculum in most (any?) schools.

So it’s common for students to share draft proposals with me to ask for feedback.

The two biggest issues I see cropping up are:

  1. There is no clear transformation defined in the situation appraisal section
  2. There is no connection made between deliverables and benefits in the project options section

I’ll talk about the first one tomorrow if you’re interested, but today I want to focus on deliverables vs benefits.

Examples of deliverables are things like:

Again...

This is a list of deliverables.

It is NOT a list of benefits.

If you want to turn a deliverable into a benefit, a good way to get started is to append “so that...” onto the end repeatedly until you get to something that your buyer probably cares about.

Let’s use this deliverable as an example:

“Implementation of an SSO feature for your enterprise SaaS product”

(Where X% is based on how much time their users waste on average resetting their passwords and/or waiting on IT support.)

Here’s the thing...

Business buyers care about business benefits.

If you can’t use the word “increase” or “decrease” in your description, it’s probably not a benefit.

Yours,

—J

P.S. The Pricing Seminar is returning in September for its tenth session. Woo hoo! Double digits ;-)

To be notified when early bird registration opens, add your email address to the announcement list here:

KEEP ME IN THE LOOP »

Stay tuned for more details...

share this page on twitterbrowse the archive