Part 4 : How to define requirements and issue a request for proposals (RFP)

After considering new opportunities, thinking through the vision and reviewing what the competition makes that addresses similar challenges, it’s time to bring it all together. Perhaps you’ll have an internal team ready to execute the project, but it’s more likely you’ll need to find a partner to help fulfil your vision. In order to find the right partner, we need to describe what we want, define our requirements and issue a request for proposals (RFP).

I’ve been on the client side writing requirements and on the agency side interpreting requirements and devising solutions. Each side of the relationship has pleasures and pains, but the task of thoroughly thinking through what one wants to achieve is common to both clients and agencies.

Requirements are not a detailed specification that one could throw at a vendor, partner or development team with a directive to “build it”. Instead, requirements are an explanation of :

  • The commercial value
  • The user value
  • Roughly, how the user will interact with the product

Getting this right at the start of a product development cycle eliminates 99% of legal, commercial and technical friction. When writing a Request for Proposal (RFP), one should focus primarily on the commercial and user value, leaving the details of how a user interacts with the product at very high level.

Most Request for Proposals (RFP) documents make the mistake of diving deeply into how individual features work without explaining its contribution to the bottom line or why a user might find the feature of value. These kinds of RFPs usually come with pseudo specifications that only half-solve a problem.

For example, a marketing manager might devise an intricate set of instructions for a brand microsite, but forget to include the commercial goal, why a customer would ever engage with the app, leave out all the possible acquisition vectors – and provide wireframes for only a handset.

Why is this not ideal? Well, one typically hires an agency for the value they bring across all the domains of creating a product – user experience, design, development, delivery and project management. By over-specifying the “how” and skipping over the “why” the client leaves the agency with no rational basis upon which to build a solution.

Conversely, the purpose of an agency is to collect domain experts together into a team and provide coherent value – forcing your clients to provide UX or detailed product specifications turns the agency into little more than cheap (or, more usually overly expensive) brute force labour.

Like so much in business and life, it’s about knowing what one wants, knowing when it’s ok to not know and working collaboratively to devise solutions.

In digital there are many, many kinds of products and projects for which one might issue an RFP – everything from a marketing campaign with elements of social, mobile and web to large products and platforms. My sample RFP table of contents will be for a larger product or service, but can easily be scaled down (or up).

product suite

Goals and purpose

  • This is where we assert the commercial and user value based on our unique vision
  • Why are we doing this?
  • What are the “jobs to be done“?

Key deliverables

  • This should be a natural consequence of the fulfilment of your vision and goals.
  • What are we creating?
  • Define this broadly and narrowly.


  • Be up front about the constraints – time, budget, competition – of the project and everyone will go into it with “eyes open”.

Inputs available at the start of the project

  • When I work agency side, this is vital to get a handle on the overall scope of what the agency needs to figure out or supply.

Content sources

  • Humans typing in a CMS, RSS feeds, an external API?
  • Are we hiring someone to build an API to both ingest and syndicate content?

Backend architecture/CMS

  • Are we building a CMS or using an off the shelf solution?
  • If no one client side is entering content, do we even need a CMS?


  • If it’s a multilingual product, who “owns” the translation memory and where is it stored?

User management

  • We need a way to manage the users of our API and our CMS – if we’re building one, of course.

User Experience & Design

  • We test our assumptions with a prototype or wireframe.
  • It’s not about how it looks, but how our customers interact with our product.
  • Make clear we’re looking for meaningful input around interaction design.
  • Request prototypes and active wireframes – not static wireframes or JPGs – and always review in situ on multiple devices.
  • Use Style Tiles or a similar approach to work out the look and feel of the product.
  • Ensure the UX/design scales from phones to desktops and be mindful about interactions that might need to be extended to home devices or wearables.

Front-end/client app

  • Typically this will be one of the key deliverables – an Android or iOS app and/or a web site.
  • Detail what our users should be able to do not the “look and feel” of things.
  • Keep in mind the jobs our users have hired our product to do.


  • How will we generate revenue?
  • Direct sales, subscription?
  • Search engine marketing (SEM), pay-per-click (PPC) advertising?
  • Display advertising, in-stream advertising, sponsorships?
  • Who will sell the advertising?
  • How will ads be trafficked to the front-end/client app?

Search Engine Optimisation (SEO)

  • The best definition can be found at moz.comSearch engine optimization (SEO) is “the practice of increasing the quantity and quality of the traffic that you earn through the organic results in search engines,” according to Rand Fishkin.
  • Make sure anyone peddling SEO services is fluent in surfacing content everywhere. It’s not only about surfacing content for Google, but ensuring our content is front and centre on iOS and Android, too.
  • Avoid duplicate content!
  • Titles and tags must reflect in the <meta description>
  • Automatically generated sitemaps, including Google News, images and video sitemaps
  • Use rel-alternate-hreflang to indicate language
  • Ensure there is a mechanism to designate the canonical category, generating a metatag on the front end with the full URL
  • Generate a full and relevant range of microdata as per standards


  • Where will our product reside?
  • In the cloud on Heroku or AWS? An existing data centre?
  • Will the client or the agency be responsible for arranging this?



  • These KPIs generally refer to the speed with which a user can access the product.
  • Page load time is the leading KPI – slow-loading sites haemorrhage users!
  • For editorial products, time to publish is another critical KPI – we live in a world of real-time publishing!
  • This can be a wooly requirement and mean different things in different contexts – be careful!

Service-Level Agreement (SLA)

  • It’s critical that one makes very clear expectations around the availability of a product/service – and time it takes to resolve critical incidents.
  • This can include :
    • API uptime
    • CMS (and associated tools) uptime
    • Front end/client uptime
    • Error monitoring
    • Platform monitoring
  • Insist on a simple dashboard and notification mechanism so you’re always aware when an incident occurs and when it’s resolved.


  • The Open Web Application Security Project (OWASP) is a terrific “first principles” resource.
  • Specificities exist for every language, platform and industry.
  • Do your homework – make sure common vulnerabilities are named, but make very clear it isn’t an exclusive list.
  • Ensure the entire toolchain and product ecosystem is accounted for in the security framework.
  • Environmental security including datacentre access policy, cooling, fire prevention.
  • Disaster recovery plan, redundancy architecture.
  • DDoS prevention and rapid response
  • Code injection
  • Middleware versioning and hiding of latent binaries and shell executables, patch management
  • Mandate regular audits.


  • Building a product or service is great, but make sure there’s a proper handover so everyone understands the value and benefit.


  • Everyone wants to build a solution, but few people or companies want to (or even know how) to operate a service and iterate a product week after week and month after month.

Case Studies

  • I always like to see how people solve similar problems.
  • Asking agencies to submit case studies is an indication of how well they’ve read the RFP.
  • As a client – when the case studies don’t reflect the RFP requirements or the industry, the response goes to the bottom of the pile.
  • As an agency – one makes very sure that the case study maps very clearly to points raised in the RFP

Example project plan

  • As with the case study, here’s where one can demonstrate a clear understanding of the requirements – and what it takes to deliver on them.
  • Ask for a classic GANTT chart exported from Omniplan or MS Project – no problem at all for a competent agency.

How to respond

My secret weapon to power through RFPs is to break the document into an outline of requirements and ask the respondents to note their compliance and the page number upon which the requirement is detailed.

In a situation where one has to evaluate multiple submissions, it crushes all ambiguity and saves a massive amount of time and effort.

  • Where to send the response
  • In what format
  • Proposition structure
  • Build vs Ops – is there a one-off fee plus ongoing maintenance? What about intellectual property or licensing feeds?
  • As a client or someone issuing an RFP, remember to be very specific here – it will make comparing responses vastly more straightforward.
Part 4 : How to define requirements and issue a request for proposals (RFP)