Product-based development vs. Project-based development

A few months ago my director and I had lunch with a couple of colleagues from another big media company where I had worked as a product manager for a few years. They were interested in adopting Agile as a more nimble and cost-effective software development process, which is something the Globe and Mail started right around the time I arrived. The conversation brought me back to my previous role and the challenges of their ‘project-based’ development process.
In that world, projects would be identified and approved by senior management, assigned a priority and then handed down to the digital production team. Resources were organized as a matrix, so there was a design and UX team, a developer team, a platform team and so on. Sometimes a project manager would be assigned, otherwise the product manager would need to fill that role. The constant challenge was hanging on to your resources. If a higher-priority project came along and they need your designer, or developer or whatever, they got them, leaving you to scramble to fill the hole and keep your project on track.
It’s done differently at the Globe. In a nutshell, we have cross-functional Agile teams organized around products, so all the key components of the business – the publishing CMS, the video platform, community/social/comments, or advertising products (the newest product team, which I’m currently running) – have a dedicated Agile team responsible for those products.
The assignment of the teams is meant to be flexible to meet the needs of the business. If the organization finds it isn’t effectively addressing the inevitable site glitches and performance issues, it can reorganize resources to create a critical issues team. If you want to treat mobile not as a separate product category, but as an integral part of the editorial platform, then create a single team with mobile expertise that has responsibility for both web and mobile platforms.
But this is pretty obvious stuff. Agile is pretty much the new standard for software development, and if your company is not iterating on some version of Agile, you should probably find employment somewhere that is. The real advantage of creating product based teams is that the teams take ownership of the product. They stick with the platform and become the experts on its stresses, capabilities and potential. With the proper management structure in place, the broad, non-prescriptive business goals of senior management are communicated to the product teams, and the team members collaborate with business stakeholders to work out the best way to achieve those goals. Projects are scoped and budgeted based on estimates and technical input from the people who will be doing the work. When you’re handed a budget, a set of requirements and a delivery date without the input of the team doing the work, you’re probably in trouble (also see Iron Triangle).
Anyone working in digital knows the phrase ‘knowledge economy’ but too often the core of that idea is overlooked in how digital companies organize themselves. It’s been over a hundred years since Frederick Taylor published The Principles of Scientific Management, yet many (most?) companies are still organized around the idea that senior management understands exactly what needs to be done, and the manager’s job is to make sure the employees execute their tasks as efficiently as possible.
But in the knowledge economy, the power is reversed – or at least more evenly distributed. The keys to a successful product lie with the people on the front line – the coders, designers, your QA and infrastructure team. They have the actual expertise to execute, and the job of management is to empower them with information and the environment that they can execute successfully in.

Once your digital department exceeds a few dozen people it’s impossible for the people at the top of the org chart to know best to resolve technical problems or make the hundreds of UX decisions that go into a good digital products. The great idea or elegant solution is far more likely to come from a clever UW intern than your VP of Digital (something our VP of Digital surely would agree with). And the role of senior management then, is to communicate the business needs and create the environment where the experts on the platform can effectively figure out the solution. This is another area where Agile really excels – but we’ll leave the for another post.

Reading List:

Agile Software Development, Principles, Patterns, and Practices Robert C. Martin – a great all-round guide to the nuts and bolts of working with Agile.

Succeeding with Agile: Software Development Using Scrum Mike Cohn – more focused on how to adopt Agile within an organization. Essential for managers and up if your organization is adopting or thinking about Agile.