Hi there.

As product folk, we like process. Most of us have systems, even if they are different. We may even like to think that we are bringing order to some chaos. But systems don’t always work or aren’t always necessary. This week we’re looking at the ability to run quick experiments and whether custom work is worth the effort and when to JFDI. And I’ve added a side note on privacy, which isn’t necessarily product. But where exactly does it sit and who should be thinking about it?  

Questions/comments? E-mail me at jodie.hopperton@inma.org. 

Should product work on custom pieces?

I often hear of product teams being asked to build one-off, custom pieces. It’s an idea for a story or an advertiser request. Not necessarily a bad idea, but it can pose a dilemma.  

Does it fit into the product process? The traditional product process starts with the problem — the customer problem. So is this request a creative problem that needs to be solved? Or a restricted business need that needs to be met? 

That depends on our definition of customer. Is an advertiser a customer? Is an internal stakeholder a customer? Comically one day last week, I was having this discussion with a senior media leader who argued that customers should always be external. As he was telling me this, I realised that I had a powerpoint slide showing a triangle of customers: users, commercial, and internal. The reason it was funny: The slide had his company logo on it and was presented by one of his colleagues at a recent event. 

I would argue that it’s OK, as long as we define what it is and how it fits into our workload. 

This is likely to mean delving into the request:

• What is the customer problem exactly? 

• What is the ROI? 

• Will other customers find this useful? ie is it something that we can reuse in the future? We use the term “productizing” something for a reason. It’s taking something and making it reusable, perennial. 

• What are the tradeoffs with other work that can be reused? How does this play into the ROI? 

I can see pure product folk rolling their eyes. No custom work isn’t true product work 99% of the time, but it shouldn’t be an automatic no either. And if we’re being honest, if the CEO asks for a one-off — even where the answers to most of the above are no — if it’s not going to take much time and will take longer to argue, and potentially damage a relationship, then sometimes the answer is JFDI.

Living in the fast lane: giving teams the ability to do quick experiments

Product as a discipline brings a focus to the customer journey. It’s a process. We like process. Except, do we always need a process?  

A major publication in London (my original hometown) told me journalists sometimes see their colleagues and friends, who happened to be engineers in the pub, and all of a sudden the thing that they had been asking product for had miraculously been spun up. Had product been informed? No. They noticed changes online in real time.  

Should product be angry? Annoyed? Frustrated? Honestly, I think not. And neither did the leader of that department. Here is why:

Because this is a defect in the process itself. To be pedantic, you could say that there is a customer problem, an internal customer problem. People will always find a way around a process if the process is too hard. 

Before you throw your arms up in despair, I come bearing a solution. Not me exactly, but several leading publications use the same solution. It’s tried and tested. And it’s simple:

Leave some capacity in your roadmap for small projects and experiments to be spun up and down quickly. Ben Haywood, director of product at Nine in Australia, summed this up well in a  recent presentation:

Gannett in the United States and The Guardian in the UK use similar methods. We work in the news business and, by default, things always come up that are unexpected. This allows you to plan for them. How much capacity depends on your team, the workload etc., etc. But if you want a number, I suspect the 80/20 rule works here: 80% planned, 20% spare capacity for fast tracking as needed.

It seems appropriate to close this with some wise words from Cait O’Riorden, the CIPO at the FT (which for the sake of clarity, is not the aforementioned London-based publication I was referring to). She told me that sometimes it’s better to focus on the small projects. Why? Because the large projects have more stakeholder, hence more opinions, and can carry a lot more risk. Here is where you really need the process.

Side note on privacy 

I’ve had a couple of questions and conversations around privacy recently, so I thought it may be helpful to share some thoughts in this newsletter. 

Privacy is complex: form capturing data, storing it securely, using it wisely, and communicating the company stance more widely. Is this a product issue? Yes and no. It’s a whole company issue and product’s position in the company often means that it either champions privacy or at least champions the discussion by asking the right questions.    

Very few companies seem to have privacy all in one place. The BBC and Schibsted are exceptions to this and have a dedicated chief privacy officer. 

Most companies breakdown privacy between departments, roughly as follows:

• Data teams handle how data is gathered/handled.

• Legal teams advise on compliancy.

• Marketing teams usually own the customer relationship (which also may have a GDPR or similar specialist).

• Communications teams are responsible for the outward stance.

• Technology often owns data protection and sometime have security teams.

Dates for the diary: October 5-19

The schedule is up for the Product and Data Summit and the pre-registration closes on October 1 — this Friday! — so sign up now. It’s a cracking line up with so much good product stuff in there from OKRS: the good the bad and the ugly, to the 10 types of innovation, culture wars, and looking at how some seriously outstanding products in news were built such as The Guardian’s live blogs and USA Today’s all new Sports Plus. Not to mention the two-hour Netflix product workshop, data transformation, audience analytics, and the cookie apocalypse. 

You can see why we need five modules to cover all this! I hope you’ll join us Tuesdays and Thursdays in October. 

Tweet of the week

In my entirely unscientific polling of product leaders around the world, the top skill they recruit for is communication. So this tweet does not surprise me at all. But it’s a good reminder that product managers need wide ranging skills. What do you look for?

Recommended reading

Getting ready to take part in the Gibson Biddle workshop at our summit? Then read this: Netflix Is a Product & Technology Company.

About this newsletter 

Today’s newsletter is written by Jodie Hopperton, based in Los Angeles and lead for the INMA Product Initiative. Jodie will share research, case studies, and thought leadership on the topic of global news media product.

This newsletter is a public face of the Product Initiative by INMA, outlined here. E-mail Jodie at jodie.hopperton@inma.org with thoughts, suggestions, and questions. Sign up to our Slack channel. 

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .