Business, Documentation

Request for Proposal (RFP) of your MVP product development

How to write Request for Proposal?

RFP – Request for Proposal
MVP – Minimum Viable Product
POC – Proof of Concept

In my career, I’ve received dozens of RFPs for a variety of services. What I can say is that styles of those RFPs differed from one another starting in size – from one paragraph short to 100 pages long, and ending on the type of details – explicit or vague. The clearest to understand and easiest to estimate were those created by experienced product managers, mostly engineers – those were the best.

What is the best Request for Proposal you might ask? I would write that the one that explicitly points critical needs, is clear to understand and generate good questions – if any – and that all together should give you access to the best offer (best means the best quality to price ratio, not the cheapest).

Of course, the details, and structure of Request for Proposal can differ by domain or market, but one principle has to be followed – analytical description. This is the clearest to understand and minimizes misinterpretation of soft descriptions.

I want a proposal for the system same as LinkedIn? The functionalities are obvious.

From my experience, RFP for industrial implementations is usually the best compared to the one for marketing project or for tech MVP. Why? In industrial procurement usually, the documentation is very clearly prepared by the engineers for the engineers. In MVP production for startups, the documentation for the offering is created by non-engineers for the engineers.

What really RFP is?

Usually, Request for Proposal should give you an answer about:

  • price estimation,
  • timeframe estimation,
  • draft for a development approach.

It should be created in a way to receive proposals for the most effective comparison.

The comparison factor is a strong principle of RFP – you should throw away bullshit proposals and stick to the most competent ones. I would say that it is the strongest element of RFP – to find best X out of Y teams, where X should be about 20% of Y of the production companies you are talking with.

To achieve that the RFP should be created as at least initial documentation for the product – which is:

  • product or service description,
  • users description,
  • the cases of use,
  • minimum requirements vs nice to have requirements,
  • any sketches, diagrams, or drawings.

If you miss some of those you risk over- or under-estimation because of things lost in translation – which can exclude good team or accept a bad team to the final pull.

The costs of misunderstanding at the very beginning can be tremendous if not in money, then definitely in the time you spent.

Small hint: when you lack something in your RFP, a good team will usually be a little bit annoying with questions about the product – it is because they want to avoid risks of under- or overestimation as well. Bad teams won’t bother you with too many questions – they will just take it as your requirements without any deep discussion.

Frequent Mistakes

You can create good RFP and don’t need to be an expert in technical documentation. Of course, it needs some practice, but you can start with avoiding some of the most common mistakes that I’ve listed below.

btw. If you have anything from your experience worth mentioning write me an email. ;)

#1 Oversimplified Description

“I want a copy of <a name of a mainstream product>

but for <anything here>”

… is the number one joke for MVP production RFP.

The problem with that statement is that most of the projects that you would want to copy are already advanced products with millions of $ invested. Another thing is that copying your future competition is not necessarily a good idea (I will write a post about that someday).

Focus a little bit on describing your idea / or concept more in the way that a high-school student would understand (I am serious). It doesn’t need to be an essay, but at least a simple brief description about:

  • What problem should the product/service solve?
  • Where would you like to implement it?
  • Who would be the first users?

Be as explicit as you can.

#2 Lack of examples

Usually, a description point by point what users do with the product or the service is enough. It should give the feeling of how it should work, and already be a good base for creating an idea of production architecture/development approach.

Any other examples of use are good, online, off-line, etc. – simpler the better.

You can use an existing product or process to describe it as well. However, if you want to be innovative, then using existing ones can create a bad interpretation of the concept for the product you want to develop.

#3 Lack of sketches

Draw, sketch as much as you can. Try to visualize the things you have in your head or described on the paper. An image is the best way to communicate the information. Use it!

If you are using screenshots or images of already existing products, you have to mark them with the things that are essential for you – critical – you want to avoid a risk of misconception.

#4 Not being transparent

First of all, not letting the production team know about any risks, or about your support in the production of the product can influence the reliability of the offer you will receive. The production team should know about anything that can influence their work. Try to answer some of the questions below:

  • What have you already done or what can be used to build the product/service?
  • What support are you providing regarding the production?
  • Will you be able to start anytime?
  • What is the deadline for RFP, workshop/documentation, product launch, etc.?
  • Have you secured funding already or not?

The answer to the last question can influence the development approach heavily. I would suggest that for MVP you should disclose at least the entry budget level – the good team will suggest fine solution how to use it best.


Good RFP can save you a lot of time and money. And most of all, thanks to that you should be able to throw out bullshit offers (80% or more promising, 20% or less legitimate feedback) and focus on the most reliable and realistic ones (80% or more legitimate feedback, 20% or less promising).

Usually what we create for our clients is a more advanced version of the above, for better offers and saving time, but it should be a good start for you when creating the RFP on your own – practice means mastery. :)



Rafał Maliszewski

Business Analyst, Project Manager, and Business Development Manager. Strongly connected to new product development, business development in all areas of technology. Great passionate to create better processes for new technology development.