How to create a good RfP for digital products and services

We have been creating digital products and services for the social impact sector for almost 8 years now.

Over this time we have received and reviewed 100s of RfPs (request for proposals) and as a result, we have a pretty good idea what makes a good RfP, and most importantly, enables a great proposal.

Below are 6 recommendations for creating a good digital RfP, written by us, on the RfP receiving end.

1) Include a budget, or at least a budget range

All RfP’s have an allocated budget. But budgets are often withheld from featuring in the RfP as a strategic mechanic to unlock the greatest value for money. This leaves your potential suppliers in the dark, 2nd guessing, and often making inaccurate assumptions.

Buyers (the RfP creators) believe that if they go into great detail with a list of features and functionalities they need, that’s enough information to create an accurate budget. It’s not, and here’s why: each feature can be built in 100s of different ways, from low fidelity hacks, and third party integrations to groundbreaking bespoke solutions. A Ferrari and a Fiat, on paper will have exactly the same features. But one costs £25k, and the other £250k.

We need to know your budget to right-size our proposal to match your vision and ambition.

2) Don’t include a fixed list of features and functionalities

The process of creating digital products and services is very different to physical products and services. Physical products are typically still built using Waterfall methodology. Digital products and services are created using Agile. This means we work in sprints (increments of typically 2 weeks cycles) building an MVP as rapidly as possible, getting it into the hands of the user, and then embarking on a journey of continuous improvement driven by feedback from the user. The user decides the features, and this is how relevant products are created.

Often we receive RfPs with a long list of predetermined features, and whilst this is a helpful reference to understand the current vision, until we begin the process, we won't know what the user needs, and the features we need to prioritise to meet the project goals. (For reference, we have never built exactly what we or our partners originally envisioned).

It’s really important that everyone is comfortable with that ambiguity, and the knowledge that we are here to facilitate the needs of our users, not the assumptions of the product owner.

3) Instead, describe the vision, the project goals, the user/s and the context

We want to know as much as possible about the project. The reason for its existence, the problem it’s solving. The information, research and decisions that led to creation of the RfP.

The goals of the project, and ideally KPIs, and any relevant other internal or external ie donor commitments.

The barriers that may hinder the goals being met, any internal roadblocks or politics we will need to navigate through / over / round. Include examples of other similar, or dissimilar projects, and explain why they are useful reference points or sources of inspiration.

Tell us everything about the user, and include any supporting research that will help us know your user as well as you do.

Sharing as much information will give the responding organisations the best chance of creating the proposal you are looking for.

4) Tell us about your organisation

Is your organisation new to digital, is this your first, or one of your first digital projects? What's the digital literacy / digital experience of the team. Don’t worry if it’s low, knowing this will help us to ensure we don’t baffle you with tech jargon.

Is your team / org risk adverse or up for breaking new ground?

Have you had any bad / successful experiences with digital in the past that may affect the mindset for this project?

What team is allocated to this project and how much time will they have to commit on a daily / weekly basis? Do you want us to be an extension of your team, collaborating on a daily basis, or have weekly check-ins?

5) Commit to good communication through the tender process

Responding to RfPs properly takes a lot of time, from a number of different team members. The team will need to rapidly learn about the organisation, project, user and goals, and then craft a relevant proposal in a tight time frame.

On this journey there will inevitably be questions that only the buyer can answer. Our best experiences are those who recognise this, and respond within 24 hours. Another best practise example to provide feedback to RfP participants. This is increasingly happening, and always invaluable.

If timelines need to be moved, decisions are delayed, that’s fine too, but please communicate so organisations know to hold or move allocated resources.

6) Most importantly come with an open, agile mind, and a desire to learn together

Creating digital products and services is a continuous journey of exploration, testing and learning. Knowing too that we will encounter things that are surprisingly hard, with hidden dragons laying beneath them, and things we thought might stump us, but instead were surprisingly easy.

A RfP that states ‘a desire to learn together’ always makes us smile, and we know then we are going to be working with a partner that has the right egoless attitude: that we are all here to facilitate the needs of the users, not indulge in our individual creative preferences or ideas.

We hope this helps. If you have any questions or would like to chat more about this please feel free to contact us at hello@hereiamstudio.com