Build the proposal

Once the team is aligned and all the necessary artifacts are collected from the Lean Requirements process—including the assumption document, scope, budget, schedule, and the mission of the product—package this information into a consumable format for stakeholder review and approval.

Don’t make the mistake of skipping a proposal for existing clients. Someone else is always gunning for your work.

The proposal is the culmination of all the work we’ve done so far—the pinnacle of what we as a partner can bring to our client. Our sales process is intentionally designed to build the maximum amount of trust, painting us and our capabilities in the best possible light because the initial burden the buyer faces is a heavy one. The client team is very likely staking its future success on selecting a partner for a multimillion-dollar initiative.

We are, however, in the software business. We propose because we know we deliver, and so we’re not afraid to stretch a little. The proposal and the MSA and SOW that follow are vehicles to transition from a sales engagement into delivering software. Each document formalizes expectations and provides the foundation to build, including parameters protecting the client (guaranteeing they receive the product/services they’ve purchased) as well as us (guaranteeing Devbridge is compensated for the work we do). These are the building blocks of a proposal:

• Product charter: Reviews the goals and measures of success
• Story map: A functional description of what the software is supposed to accomplish
• Estimate: A detailed breakdown of functionality, associated effort, and assumptions made for the work.
• Proposal keynote or PDF: A presentation that outlines all artifacts, including estimates, timelines, team configurations, and technical considerations.
• Technical proposal keynote or PDF: A detailed narrative around architecture, selected technologies, and agreed-on best practices (e.g. automated test coverage, security)
• Prototype: Shows the product in action via static design mock-ups or video demonstration. Extra bonus points if the client isn’t expecting to see a prototype during the sales process.

No two purchasing experiences are the same. Some are fast and decisive, perhaps endorsed by past experiences. Others are slow, laborious, and require significant due diligence. But in both scenarios the sponsor puts their neck on the line by bringing in a vendor they choose. It’s a leap of faith, considering that the majority of IT projects fail. A well-crafted proposal is a final artifact that equips the sponsor and fortifies their confidence. Furthermore, it’s the first asset for remarketing services inside the account.

A proposal is a story that builds trust.

As a reminder, a proposal creates additional value and trust in the buying process. Repeating and reiterating what has been already discussed in the workshops is intentional.

What is a reasonable investment?

You may be thinking that the effort of proposing to do the work carries a significant overhead—why not just tell the client we can do it, save a bunch of time and money, and jump right into problem solving? Not so fast, gunslinger.

Consider for a moment the lifetime value of a strategic account. A Fortune 1000 may hire us to build a new insurance portal, estimated at $750,000 for the MVP release. That product is likely to have a roadmap beyond the initial release, not to mention other product lines that we can win over once we demonstrate our speed and quality. Proposing, delivering, and retelling that story may lead to an account that has a spend of $4 million a year, totaling $20 million over the next five years. Knowing that the lifetime value of an account is $20 million, what is a reasonable amount of effort one should spend on winning the work? Even a $50,000 prototype doesn’t seem all that excessive. Investment in the proposal stage is all relative.

We often make a mistake on our existing accounts and underinvest in the sales process. We have a healthy relationship, we tell ourselves, why waste time on telling the same story over and over? And in most cases, we’d be right. But consider the following:

• The client may be sharing your proposal with a boss, and there may be additional workstreams that can be unlocked.
• Any smart CIO or CPO always evaluates options and landscape of service providers. The current product may be getting bids from a few other partners.
• There may be new capabilities at Devbridge that the client is not aware of, and the proposal could broaden our reach and workstream.

Going above and beyond

Each touchpoint is an opportunity to further improve the goodwill of the client. A stellar capabilities presentation and an outstanding workshop can be dulled by a poorly written, ill-designed proposal keynote. It says, “We’re great at sales, but you can expect our delivery process to be less polished.”

When putting the proposal materials together, consider the following:

• Cohesive storytelling. The proposal must be readable from start to finish as a stand-alone document. It should explain the solution, method for delivery, etc. Think about how it would be perceived by a senior executive who hasn’t participated in the workshops.
• Quality and polish. Proofread the document after all the copy is added. Ensure the quality is consistent across slides. Intentionally design new slides for this proposal.
• Target audience. The messages and language must be appropriate for buyers, and all content should reinforce the overall vision for the product and the values of the client’s organization.
• Future state. The proposal should describe and visualize the desired future state of the product—remember that all buying decisions are emotional. Stakeholders desire to be at the end state as soon as possible, so telling this story in the proposal is incredibly powerful.
• Concerns, industry landscape. Identify and explain all risks, evaluate the industry landscape, and explain how the solution will work around both.

Last, remember that a proposal is an opportunity for a tailored “capabilities” presentation with a much higher level of customization and fidelity. It is also a story, and all storytelling best practices apply.

Building blocks of the proposal

The following artifacts are part of the package that is presented and distributed to the client. Each proposal is built as a deck and delivered as a PDF. There is no one-size-fits-all. Consider these building blocks when you assemble the proposal:

• Industry landscape, challenges
• Business problem and product vision, future state
• Quantified success measures
• Workshop summary, story map
• Product charter
• Entity map
• Technical requirements, integrations, architecture, stack, etc.
• Testing framework
• Release life cycle
• Delivery process explanation, team structure, etc.
• Delivery schedule (MVP versus expansive)
• Estimate associated with each version
• Assumptions locked in
• Prototype presentation (the big reveal)
• Getting started, next steps

Communicating the estimate clearly

Always try to deliver your proposal in person. Demonstrate, explain, and involve the client in the estimate presentation. Show how each component relates to one another and requirements intertwine. It’s important that the proposal presents the estimate in great detail. There are lots of factors and detail to communicate that can be easily lost in translation if not presented clearly.

A few best practices for presenting estimates are to explain the following:

• Devbridge’s approach to the estimation process—it’s a planning tool, not a feature guarantee
• The assumptions
• The delivery metrics used to align reality to estimates
• The need for Agile, ability to pivot, test, and iterate while building the product
• The estimate document also contains the following tabs:
• Digitized story map
• Assumptions
• Engineering architecture assumptions
• Team ramp-up for delivery

Responding to an RFP via email lacks control, context, and puts the deal in jeopardy—plus, in some cases, the client could kill a deal because of unknown evaluation criteria. When in person, the person tasked with presenting the proposal and estimate is positioned to address the unknown and react to shifting attitudes in the room.

Wowing with a prototype video

Not all opportunities require or deserve a high-value production such as a prototype and a video. However, err on the side of caution with strategic accounts. Yes, the team is in the bag and represents the most beloved vendor in the mix, but people change jobs, economies go south, and even the team sometimes fails at delivery. Building trust never stops.

These videos are incredibly powerful because they get distributed inside the clients’ organizations where they continue to build trust, and they are completely unexpected. This is a great example of underpromising and overdelivering.