Sent by Jonathan Stark on December 22nd, 2018
Let’s say Alice is a software developer. A potential client named Bob from CamCo approaches her about building a bunch of features into CamCo’s cloud-based security camera SaaS application.
In his initial contact, Bob rattles off a list of features CamCo needs built, he asks if Alice can do this kind of work, and he asks what her hourly rate is.
Being an enlightened individual, Alice replies by saying:
“Sure, I can do that kind of work, but I don’t have an hourly rate. If we can talk a little more about the project and I think that we’re a good fit, I’ll give you a fixed price for the whole thing. Would that be acceptable?”
Being an enlightened client, Bob responds by saying:
“A fixed price? That sounds amazing! Let’s talk tomorrow at 3pm ET.”
On the call, Alice undertakes The Why Conversation in order to uncover the underlying motivation for the project. Bob explains to Alice that this project is part of an effort to land Starbucks as a client for their security camera monitoring product.
Alice asks some follow up questions about traffic and bandwidth and I/O to understand how big Starbucks is compared to Bob’s existing client base. The numbers are staggering and Alice indicates that even if the software build was free, they’d be looking at a non-trivial infrastructure upgrade cost.
Bob agrees with Alice’s assessment and reveals that landing Starbucks would roughly triple CamCo’s revenue from $10M to $30M overnight, so the infra costs would be negligible.
Okay, great. Alice got a desired business outcome from Bob, and as a bonus there was a dollar amount attached.
Does this mean that Alice can use the $20M revenue increase as the basis for her value price?
In the conversation, Alice also learned that CamCo’s staffing and administrative costs would roughly double from $5M to $10M, so the net profit of landing Starbucks as a client would only be $15M not $20M.
Does this mean that Alice can use the $15M net increase as the basis for her value price?
As a software developer, Alice has virtually no control over landing Starbucks as a client for CamCo. She could write the most elegant code ever, and still there would be probably twenty CamCo employees who could fumble the ball on the Starbucks deal.
In her role as a dev, she has no direct control over CamCo landing Starbucks. So, Alice needs to find something upstream from the Starbucks deal that:
What might that conversation look like?
Something like this:
Alice: “From what you’ve told me so far, this is sounding like a really big software project. And really big software projects are expensive and risky. I’m probably being naive here, but... I don’t see a straight line between 1. investing all this time / money and 2. landing Starbucks as a CamCo client. What am I missing? Why not just ramp up the sales team and sell Starbucks on the product as-is? It’d be significantly cheaper and less risky.”
Bob: “Fair question, thanks for that. Carol C., our SVP of Sales came to us from Starbucks last year. While she was there, she was in on discussions about switching away from their current security cam vendor, VeriCam. We know that Dennis D., the Starbucks COO is dying for a few capabilities that VeriCam doesn’t offer. If we can beat VeriCam to market with these features, I think we stand a decent chance of landing the business. We could hire all the sales people in the world, but they’d never convince Dennis to switch unless we have a compelling differentiator.”
Alice: “Gotcha. That makes sense, thanks. Hm... could you differentiate from VeriCam by staffing up and delivering these new features to Starbucks as more of a concierge service instead of building it all as self-service software?”
Bob: “Perhaps, but... that approach would be a tougher sell. And it would seriously eat into our margins on an ongoing basis. A software project would be a bigger upfront investment but after the first year or two, it’d pay for itself.”
Alice: “Okay, I’m convinced that a software investment is the way to go. The next question is this: how much do you know about what Dennis wants from these new features? I’ve seen plenty of companies spend millions building the wrong thing.”
Bob: “Same here. Well, we have a high level understanding of what he’s looking for but that’s about it.”
Alice: “Any idea how we could hedge our bets? Could you, Carol, Dennis, and I have a meeting to discuss exactly what he’s looking for?”
Bob: “That would be great, but it’s highly unlikely. But now that you mention it, we have a former Starbucks security person (Ellen E.) who followed Carol here. She was involved in the day-to-day monitoring and reporting that Dennis oversees. Ellen used VeriCam every day and she hated it.”
Alice: “That’s great news. What if we build something that Ellen loves compared to VeriCam? Do you think that would give your sales team something compelling to bring to Dennis?”
Bob: “Hm... that’s an interesting idea. We could spin her experience with the beta software into a sales narrative that positions us favorably and credibly against VeriCam. I imagine that the fact that Ellen used to be at Starbucks would make it even more convincing to Dennis. We could use specifics of their internal process generically in our marketing while campaigning for their business.”
Alice found something that:
In other words, Bob has stated that he believes that Ellen loving the new CamCo software is a reasonable leading indicator of their eventual success landing Starbucks as a client (a lagging indicator).
This is great!
Alice can measure Ellen’s opinion of the software while the project is in progress. Once Ellen reports that she “loves it compared to VeriCam”, Alice can declare victory. This gives Alice something to control, something to price, and (potentially) something to guarantee.
Does this mean that CamCo will land Starbucks as a client? No, but that’s not Alice’s problem. Alice’s problem is building something that Ellen loves. And Alice is confident that she can do that.
More on leading and lagging indicators tomorrow. Stay tuned!