Software Product Owner vs. Technical Project Manager?

For the last ten years I’ve lived and worked in various parts of the UK (London, Belfast, York). Much of the tech sector in the UK resembles what I experienced in the United States in the ten years prior. However, one thing I did note after my move across the pond was a noticeable emphasis on the notion of “project” as a means of justifying business cases and signing off funding for bits of technical product delivery.

As Agile (or “lean”) became the de facto philosophy across enterprise, services and product shops, it was remarkable to me how often resource allocation and budget assignment was (is?) still conducted on the basis of a project-management mentality.

Something like Kanban has its roots in continuous delivery systems (like car production lines), but within the lucrative financial sector in the UK, project management philosophies (like PRINCE2, AgilePM, PMBOK) are still used to outline delivery plans and cost estimation for much of our development work. These tend to be more structured in their approach, although methodologies like PRINCE2 can be remarkably “Agile” when applied in the right way. This tendency toward project-management is due in part to an emphasis on these approaches by the UK government since the 1980s as part of its procurement and certification processes.

I recall working on a “project” within a well known insurance market in the centre of London which involved significant rework to an internal system handling aspects of end-user security. By its nature this was an evolution of an existing technical service, albeit including some aspects of analysis, RFP, procurement and migration. For a technologist, the work was essentially an architectural migration piece, coupled with some fairly involved R&D. However, this work was complicated by the fact that funding had to be justified and approved internally as part of a single yearly budget allocation, including a stated project plan and up-front cost estimations.

Things have moved on since then, but most organisations I have worked for over the last ten years are attempting to follow the arc of a static project plan, allowing the detail of implementation to follow an “Agile” process like Kanban or Scrum, led by a Product Owner. In this context the Product Owner has the unenviable task of bridging the gap between the project-centric delivery view and the Agile/product-centric delivery view.

Ultimately, the notion of a project is popular because it allows a business to limit the risk around budget allocation by requiring pre-estimated costs and resourcing requirements, and some idea of what it is the business is buying itself. In the same way, the notion of backlog priority and timeboxed iterations are popular Agile tropes because they allow teams to limit the risk around delivering actual business value.

Both of these notions are useful, and pragmatic to realise, especially within a modern business context. But sometimes in our attempt to limit risk we forget that the thing providing value is the product or service being created, mutated or decommissioned. Somehow we need to find a way to restore focus to the substance of what we are building — to visualise our abstract digital outputs in ways that a business can appreciate and understand.

We need to make our digital architectural assets as tangible as the physical buildings produced by our IRL colleagues. Seeing is still believing and many people find looking at a project plan the only realistic way to visualise what we are doing. I’m on the lookout for ways to bridge that gap.