How to Use RFP in Product Development Process

Have you had to write an RFP for a digital product development and felt something was off? Should you know what to do or how long it will take? After all, you are not a product manager or product designer. Yet, everyone expects you to talk about the solution and propose a detailed timeline like:

• 2/15/2021: RFP released to selected vendors
• 3/1/2021: Proposals must be submitted
• 3/15/2021: Shortlisted vendors will present their proposal
• 3/29/2021: Vendor selection
• 4/12/2021: Project start by the successful vendor
• 7/12/2021: The website is to be live

Many organizations use RFPs when they deal with 3rd-party vendors. It gives them a sense of control over the budget, timeline and result.

Modern product development teaches us that such a control is illusory. Uncertainty is a part of digital product development. Methodologies like Lean Product Process, Design Thinking, or Double Diamond don’t try to suppress it, they work with it. They translate uncertainty to hypotheses and validate those hypotheses along the way.

Problem space versus Solution space

What else these methodologies have in common is agreement that, before you solve the problem, you need to understand and define it. While doing so, you are in the problem space. Once you work on a solution, you enter the solution space.

According to Dan Olsen, many new products fail because teams jump right into the solution space without thinking about the layers in the problem space.

Where a typical RFP stands

Double Diamond, another popular design process and the one we practice at Xfive, illustrates the problem and solution spaces on two diamonds. The halves of diamonds represent divergent and convergent thinking:

• The first diamond represents the problem space. We understand the problem through discovery and research (divergent). Then define it by analyzing and synthesizing our understanding (convergent).
• The second diamond represents the solution space. We first ideate potential solutions to the defined problem (divergent). Then we test and implement the solution that works (convergent).

Let’s look at where an RFP stands in this process. The following diagram maps the Double Diamond on a two-by-two matrix. Top and bottom quadrants represent agile and waterfall processes.

Many RFPs skip the problem space and jump right into the solution space — they contain site maps, wireframes, functionality description, timelines.

What this means is that the organization’s staff tries to do the work of the vendor’s product design team.

Organization’s untrained staff substitutes the work of a vendor’s product design team.

Then come vendors trying to understand the prior work in the problem space and fit it into the confines marked out by the RFP. Their proposals should validate the solution or even ideate additional directions. All this in exchange for a subtle chance to win the project.

If the vendor is a practitioner of modern product development, this goes against their instinct. They know this is not how you design the right thing and how you design things right.

But more importantly, is this in the best interest of the company which publishes the RFP? In the desire to control everything, they are now off to a path which is the least likely to lead to a successful outcome.

Better use of RFPs in product development

If you have to use RFPs because your organization requires it, here are a few tips on how to do it more in line with current best practices in digital product development.

First, clarify where you stand. Are you trying to understand and define the problem? Or are you already looking for a solution to the defined problem?

RFP for the process

You shouldn’t try to substitute the work of the vendor’s product design team. Ask the vendors how they would approach the challenge your business has. Make your RFP about the process and past project examples. Avoid asking for a specific timeline and budget.

Instead of timeline and budget, gain confidence that the selected vendor approaches the problem the right way.

RFP for the problem space

If your company operates under stricter rules and you need to know the budget for any 3rd-party vendor engagement, your first RFP could focus on the problem space. If you split the challenge into smaller parts, vendors are more likely to come up with realistic estimations.

Base your second RFP on results of the problem space work. This is also a safer approach. If you find out that you are focusing on the wrong problem, you can avoid wasting resources on its solution.

RFP for the solution space

Have you gone through the problem space? Are you confident that you are solving the right problem? You can issue an RFP for the solution. Collect all your findings from the problem space. What kind of discovery or research did you do? What are the conclusions from your discovery and research?

RFP for the problem and for part of the solution space

Ask for a proposal that defines the problem as well as a part of the solution. This phase would end after the divergent stage of the solution space. It would provide you with prototypes or design directions to test and implement. Then you can issue another RFP for the technical implementation of the solution.

RFP based on the innovation type

Finally, you can think about what type of innovation you are actually working on. Roman Pichler (Strategize, 2016) describes three types of innovation:

• core innovation – optimizes an existing product for an existing market, requires low validation effort and poses low risk
• adjacent innovation – creates a new product for an existing market, requires medium validation effort and involves medium risk
• disruptive innovation – creates both a new product and a new market, requires high validation effort and involves high risk

Think about the problem space as a validation effort — the problem space diamond can be smaller with core innovations. It needs to be bigger for disruptive innovations. These require much more effort to validate whether we are solving the right problem.

For core innovation, it might be safe to define the problem using only your intuition and existing knowledge. However, the stakes are much higher with adjacent and disruptive innovations. We don’t recommend leaving out the proper problem space work or doing it in-house. Unless, of course, you have trained professionals.

Conclusion

Request for Proposal is a tool deeply rooted in processes of organizations and business.

As the name itself suggests, it asks vendors to propose something. In most cases, it’s a solution to a problem often defined without proper discovery by the organization itself.

As we explained, framing the problem and finding the right solution are both time-consuming tasks, which require knowledge, skills and experience.

Vendors rarely approach the unpaid task of RFP preparation with the same enthusiasm as the design process itself. You can expect that, in order to win the RFP process, they will use shortcuts and approximations and even overlook potential problems.

While it is tempting to use RFPs in order to control the budget, timeline and output, there are often better ways to achieve the best outcome for your business and customers. Ready to submit your project RFP to receive a response? Contact us today!