Shifting gears: teaching product teams to fish

I’ve been working away from my home in London for the past month on site in Doha with the beIN Media Group.

Last year I designed and led the development and delivery of a new content distribution platform and refreshed mobile/TV apps. This year it’s about fully exploiting this Core Platform: developing new tools and strategies to monetise beIN’s first class content. Some exciting developments on the entertainment front, too!

Part of my individual mission is to teach colleagues to do what I do: take business (marketing, sales, editorial) requirements and turn them into product requirement documents (PRDs) or similar specifications. But the principle I’m really trying to teach is how to make decisive choices supported by data within a set of constraints.

That’s the real trick!



Shifting gears: teaching product teams to fish

A Minimum Viable Product Is Not a Product, It’s a Process

Superb deconstruction of the meaning behind “minimum viable product” from The Macro.

How an MVP actually works.png
How an MVP Actually Works (from the article at The Macro)
A Minimum Viable Product Is Not a Product, It’s a Process

Choose your customers. Choose your clients.

“This is a choice, a huge one in the life of the freelancer, the entrepreneur or anyone who seeks to engage with the marketplace.” – Seth Godin

Key concepts when working either as a client or at an agency.


What should a front-end developer know in 2016?

I spent much of the summer of 2015 in Paris working with an agency’s development team that had seriously gone off the rails. I was the client and part of my mission was to assess the true capability of the assembled team.

This is a conversation I had with a very nice developer who the agency claimed was a senior front end developer:

“That menu is wonky and the UI lags horribly. Why don’t you optimise or rewrite it?”

“My Javascript isn’t very good.”

“I see. How’s your CSS?”

“Well, it could be better. I don’t really work on that here.”

“Are you better with the backend? How’s your PHP?”

“I want to learn more about PHP.”

“Ah ok. Well, what happens when we have a problem like this with the menu?”

“A tech lead who reviews our work from time to time, but he isn’t available until later in the week. I’ll ask the business unit director when we can speak.”

This developer was clever and friendly, but clearly not able to work on a complex project independently.

The agency fundamentally failed this developer by leaving him adrift with no meaningful support. Absent agency-side leadership, I stepped in and rallied the team – and made sure support mechanisms were put in place when I returned home to London.

Developers don’t need to know the JS hotness of the month, but they do need to possess knowledge of the fundamentals, know what they don’t know – and, most importantly, be flexible and know how to find the answers.

There’s a brilliant episode of the Shop Talk podcast that considers “The State of Front-End Dev” and how mixed-skills teams can work, “what it means to be a senior developer” and some of the challenges in defining just what should a front-end dev know. Essential listening to anyone building products in 2016!

Episode 193 of the Shop Talk podcast, “The State of Front-End Dev”

What should a front-end developer know in 2016?

Mesh networking, the Internet of Things, Pervasive Computing – let’s build the future now!

Mesh networking, the Internet of Things (IoT), pervasive computing – these are all threads in the fabric of our everyday (near future) lives.


Google provides superb machine-learning. Apple contributes gorgeous devices and (relatively) seamless user-centric experiences. Companies like Dropbox, Amazon and, intriguingly, Upthere offer unlimited, always-available storage.

But we don’t yet have the software or the infrastructure that knits everything together.

This is such a thrilling time to be working toward building interoperable, cohesive, compelling experiences for myself, my friends, my family, my community.

Let’s go!


Mesh networking, the Internet of Things, Pervasive Computing – let’s build the future now!

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)

Meta-platforms – the key to understanding our new digital product development landscape

Rise of the meta-platforms and the new ‘web browser’