August 16, 2022
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:
- There is no clear transformation defined in the situation appraisal section
- 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:
- A two-day workshop to teach your data scientists the basics of human-centered design
- An executive summary of the competitive landscape in a new market you are considering
- Implementation of an SSO feature for your enterprise SaaS product
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”
- ...so that the end users can login more quickly and reliably
- ...so that they spend less time locked out of the system
- ...so that their productivity is increased by X%
(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:
Stay tuned for more details...