Choosing the product development method that works best for your team

An introduction to product development terms and methods

Presented by Paul Rissen

When developing digital products and services, teams face the question of how best to approach tackling the work itself. Depending on your organization, you may be expected to deliver something at a specific point in time, at regular intervals, or simply as often as possible.

Even when there are no expectations set, as the product person on a team, you can help play a significant part in agreeing upon a rhythm of work that suits the team, the situation, and helps deliver a product that meets the needs of both the business and the customers. Product development methods, frameworks and processes are ways of organizing the work to achieve just that. Many of these methods have a long and storied history, not just in the digital context, but in industries such as car manufacturing as well. Others are constantly emerging and being adapted in the pursuit of more effective, and satisfying, ways of working.

This guide will give you some ideas to consider when choosing from the wealth of options available to you, but it’s important to remember that there is no ‘one true way’ of developing products. Methods, frameworks and processes are intended to be like training wheels on a bicycle — aids to help keep you and your team on a successful path. If you feel something in an established method isn’t quite working for you, you can change and adapt it to come up with your own ways of working. A method should not dictate what you do and how you work. Instead, select the parts that help, and focus on working with your colleagues to come up with a process that is clearly understood and ultimately benefits you all.

IN PRACTICE

Use the tips and concepts in this section to cultivate a product culture in your newsroom

Fit the method to the context

Avoid deciding upon a method without first considering the context of the product you’ve been tasked with working on. One method isn’t inherently better than another — it’s all about picking the right tools for the job.

Traditionally, “waterfall” methods have been preferred for work with a fixed, immovable deadline, or when critical consequences for peoples’ health and safety are on the line. If you have more flexibility, you might consider a “lean” method that allows you to deliver, learn and iterate in release cycles, thus avoiding risking it all on one big release. By doing the simplest, most useful thing, you can often minimize the cost of failure and recover with little or no harm done.

Consider the experience and comfort levels of your team

As mentioned, methods and processes are akin to training wheels on a bike. For less experienced teams, specific processes and methods can provide comfort and certainty when tackling work. Sometimes a little structure can go a long way, but be wary of allowing process or delivery for its own sake to become the norm.

More experienced teams, however, may feel constrained by the structure. As they mature, allow your teams to adapt and focus on the tools that work for them. Remember, though, that methods also create accountability, aid communication and clarify responsibilities. Be wary of getting so loose with your process that chaos takes hold.

Agree upon a cadence for organizing the work

The product manager’s role is to clearly communicate priorities and to help the team focus and avoid scope creep, while also thinking ahead to what’s next.

Different methods promote different ways of planning upcoming work. The “sprint” process sets a regular rhythm (often, but not limited to, two weeks) for teams to work on particular tasks. This method requires regular planning sessions and backlog prioritization.

The “Kanban” method encourages teams to continuously pick up the next most important task to work on. This method allows teams to focus on the work itself, but can result in more uncertainty as teams recalibrate on the fly in response to priorities that adapt as work is completed.

Set expectations by communicating how you work

Establishing how you work as a team sets expectations for the day-to-day functioning of your immediate colleagues, but it’s just as important to make sure others outside the team understand how you approach tasks.

Whether you plan in quarters, sprints or are continuously prioritizing your backlog, a key skill for a product manager is to share your team’s chosen approach. Your efforts should ensure that other teams understand not just your progress, but how, and why, you’re choosing to work on certain things in a certain way.

Getting into a rhythm of regular sharebacks and showcases, inviting not just those who depend on your team, but adjacent colleagues too, helps set expectations and builds confidence and trust in you and your team.

The differences between agile and waterfall development. (Source: Saigon Technology)

TERMS

Definitions for product terms referenced in this guide are sourced from NPA’s crowd-sourced product glossary

Agile

A product development style with frequent, iterative launches or releases.

Iterative process

A series of steps used to build on and improve a product. In development, this often means short cycles of testing with audience feedback early on to guide progress or future goals.

Kanban

A workflow management style that prioritizes efficiency and continual delivery, over fixed releases of product. Tasks are placed in columns like Not Yet Started, In Research, In Design, In Development, In Review, or Completed to show work in progress.

Sprint

A defined period of time when a team works to complete a set amount of work; common in agile development styles.

Backlog

A list of the bug fixes, new features, changes to current features, systematic overhauls, or other items a team is working on. The backlog is often prioritized internally based on needs or resources.

ABOUT THE AUTHOR

Paul Rissen

Paul Rissen has worked in digital product development for 15 years, with almost ten years working with the BBC covering the development of the first version of iPlayer and various education and news products. Stepping into the role of product manager, Paul has spent the last six years working in agile, lean and Kanban product teams, with a range of publishers inside and outside of journalism. He wrote a book specifically about experiment-driven product development, and has taught courses and delivered keynote talks on information architecture, the crucial role of structured data, narrative architecture and product development methods.

Puedes leer la guía traducida y adaptada al español por nuestros aliados de SembraMedia aquí: Elige el método de desarrollo de Producto que mejor funcione para tu equipo

Você pode ler o guia traduzido e adaptado para português por nossos aliados da AJOR aqui: Escolhendo o método de desenvolvimento de produto que melhor funciona para sua equipe: uma introdução aos termos e metodologias do desenvolvimento de produto

Puoi leggere questa guida tradotta e adattata in italiano dalla nostra associata Clara Attene: Scegliere il metodo di sviluppo del prodotto che funziona meglio per il tuo team