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.

Ultimate Irony: Could Balsillie and Lazaridis save Blackberry?

A month or so ago The Globe and Mail (my employer) published an epic behind-the-scenes story on the downward spiral of Canada’s tech giant. The article details two huge strategic decisions the company made in 2012 which significantly influenced where the company is today.

Co-founder and former CEO Mike Lazaridis has alwanys been a fan of the physical keyboard. It’s what always set Blackberry apart and it’s what the empire was built on. But Lazaridis was no longer in charge, and the company was going all-in with the Z-10, an all touchscreen device. Lazaridis argued against it in a boardroom showdown detailed in the Globe article. But physical keyboards were no longer coin of the realm in the smartphone world, according to Blackberry’s new senior management. They were going to take on Apple and Samsung, and prevail.

Earlier that same year, the other co-founder Jim Balsille had departed as co-CEO over the board’s refusal to back Balsille’s ambitious plan to license Blackberry’s popular BBM software to carriers. Balsillie’s plan would see BBM available as pre-installed replacement for SMS messaging on any new iPhone and Android handsets they sold. Lazaridis didn’t back Balsillie’s plan, and neither did CEO Thorsten Heins. Balsillie quit.

Jumping ahead to November 2013, it’s hard to see how, had Blackberry backed Lazaridis and Balsillie’s plans, the company could be worse off today. Building great handsets is hard, but building great software for handsets – including a ground-up operating system, is really, really hard. And if you’re going up against Apple and Google – well.

I know lots of people who still use Blackberrys, and it’s for the simple reason that they prefer the physical keyboard. Give them reliable email and a reasonable web browser and that’s all they need. I think Lazaridis was right on this one. Focus on making the best damn smartphone with a physical keyboard and you will always maintain a loyal customer base, customers for whom an iPnone or Android handset is a non-starter.

And for Balsillie’s plan? Well in late October (2013) Blackberry eventually did release BBM for iPhone and Android. As of this writing, one week in, the software has been downloaded 20 million times, which immediately increased their global user base by 30%.

Blackberry’s troubles clearly run deeper than these two issues. But with the benefit of hindsight, it seems that the strategies of the ousted co-CEOs were at least as good as anyone elses. Perhaps the fatal mistake they shared was in not backing each other. And that would be the saddest irony of all.