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.

Challenges

  • 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?

Translations

  • 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.

Monetisation

  • 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 schema.org standards

Hosting

  • 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?

Domains

Performance

  • 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.

Security

  • 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
  • HTTP/SSL
  • Mandate regular audits.

Training

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

Operations

  • 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)

“Jobs to be done” and B2C product development

The job, not the customer, is the fundamental unit of analysis for a marketer who hopes to develop products that customers will buy.

Clayton Christensen on “What Customers Want from Your Products

Quote

Part 2 : Refining your vision, from mission statement to actionable intelligence

In Part 1, I introduced a set of “guiding questions” one can pose before embarking on a cycle of product development or as an aid to focus a project team on a specific goal. They’re useful questions to ask whenever one wants to challenge assumptions and shake the tree a bit to get at the truth of a given situation.

But sometimes one doesn’t have a clear solution in mind or one needs to overhaul an existing, underperforming product or service. Best to go back to basics to ground oneself by defining an overarching goal and supplement with some intelligence about how to achieve that goal.

Refining Our Vision 

  • What’s our vision?
    • E.g., our ultimate goal – the global leader in delivering amazing sport content anywhere, anytime
  • What’s our mission?
    • E.g., state broadly how we achieve the vision – e.g., “producing market-defining products to deliver our best of breed content to the world”
  • When will we know we’ve succeeded?
    • E.g., which metrics and KPIs will we use to measure progress toward our mission, fulfilling our vision? Increased subscription revenue? x% more page views or marketshare?
  • What will contribute to achieving our ambition ?
    • Core product or service
    • Who are our customers?
    • What “jobs to be done” do our customers want?
    • What makes us different from our competitors?

This technique works for commercial propositions as well as products and services – and prepares one for devising a concrete set of product requirements.

vision and mission development worksheet
A useful grid to help you refine your vision, supporting mission statement and to define specific products and “jobs to be done” to further your goals.

Continued in Part 3.

Part 2 : Refining your vision, from mission statement to actionable intelligence

Part 1 : So you want to build a successful and profitable web site, mobile or home devices app, service or platform?

Often when I tell newly met acquaintances how I make my living this statement/question arises – “I have an idea for an app (or website, etc) – tell me how do I make it?” Where to begin? Perhaps with a quick overview of my previous experience. Over the past 14 years I’ve made a wide array of products and services, monetised through advertising, subscription and mixed revenue models :

  • Streaming video portals
  • Screen savers
  • Advertising creatives
  • Flash-based games
  • Marketing microsites
  • Educational assessment
  • Breaking news, live video & video-on-demand sites and apps

Despite differences in scale and diversity, all of these products began by answering a series of “guiding questions”. These aren’t the classic “five whys”, but instead help lay the foundation for further development of your idea or proposition :

  • How would you describe this in 60 seconds?
  • What problem does it solve?
  • What is the service?
  • What is the opportunity?
  • Who are the competition?
  • What is our competitive advantage?
  • How will we monetise this?
  • What is required to deliver this?
  • What don’t we know and how will we find the answers?

If you’re able to quickly answer these questions, you’ll be well on your way toward making a commercially viable product or service.

This will be the first in a series of articles discussing how one conceives of, constructs, delivers and maintains a digital product. It’ll be a blend of commercial considerations, project management, product delivery and technical development.

Continued in Part 2, Part 3.

Part 1 : So you want to build a successful and profitable web site, mobile or home devices app, service or platform?

The expert

I’ve been in meetings like this before. A brilliant takedown of ill-considered requirements and dysfunctional group dynamics.

Video

John Matthews, International Digital Business Traveller

Prior to 2012 I worked with a fair number of international stakeholders and occasionally paid visits to Boston or Milan, but was primarily based in London.

Since the start of 2012, I’ve spent significant stretches of time away from home consulting with clients in person. It’s been an amazing experience to move beyond tourism and learn about different cultures through developing content, products and services.

All this travel led me to develop  techniques to optimise my efficiency whilst on the road. My most effective tool was the purchase of a 3G-equipped iPad and keyboard case, though recently I’ve had to work more with with colleagues who can’t quite shake the habit of using MS Office documents so I’ve added a MacBook Air to my armoury. The Air also affords me more file storage and functionality when I’m away from home for weeks at a time.

When I look at where I’ve spent my time, I came up with the following (excluding travel time and overseas holidays) :

2012

  • 2 months in Paris consulting with clients (spread across 2 and 3 day visits)

2013

  • 2 months in Paris consulting with clients (spread across 2 and 3 days visits)
  • 1 month in Doha consulting with clients
  • 1 week Slovakia with my development team
  • Several days in Slovenia on an “employee of the year” mini-break

2014

  • 7 weeks (and counting) in Doha consulting with clients

As I contemplate another several weeks in the Middle East, I found this piece by Michael Lopp articulates very well how to make travel as frictionless as possible : Practical Advice for the Obsessive Compulsive Traveler.

See you somewhere between London, Paris and Doha soon!

John Matthews, International Digital Business Traveller