Author Archives: Dan Merriman

wall of product backlog post-it notes

Reflections on Product Ownership

In my day job, I do not call myself a Product Owner.

My title is Project Manager, and I think this is an accurate representation of what I do. I ‘manage projects’, in the sense that I do my best to ensure that projects are organised, run smoothly, and achieve outcomes that leave my clients feeling satisfied.

In a previous life, I have worked as a Product Owner. I worked for a large organisation that used their own version of Agile methodology across the board to deliver both new products and ongoing Business-As-Usual work. I was not a Project Manager there: I was a Product Owner. At least, that was my title. Whether I was actually a Product Owner, in the strict Scrum sense, I’m not so sure.

As the name suggests, a Product Owner is someone who owns a product, which is to say the “Vision”, as well as the Strategic goals and Tactical development of a product. This is part of the definition given to me by Roman Pichler, one of the foremost experts on Product Ownership and host of a two day workshop that left me with both an enormous sense of enthusiasm for the potential of the role and the nagging feeling that, despite what my memory and CV tell me, I haven’t actually been a Product Owner at all.

But first, let me discuss some elements of the course itself. I have to admit to a certain degree of scepticism towards such things, if only for the sheer number of offerings out there. With no rankings of the courses available, or accountability for many of the large organisations that deliver them, how do we ensure that the course we take is actually useful? Experience of such workshops, not just in business but in my previous life as an academic, suggest that there are two main factors that determine its usefulness.

First, does the instructor know what they are talking about? Do they have experience of the role in the ‘real world’, under fire, where life, politics, and Murphy’s Law conspire to ruin perfectly curated Agile processes? Do they rely on a textbook for delivering the course content, or do they have the expertise to share their knowledge in a way that adapts itself to their audience’s needs? Can they respond to their battle-hardened, sometimes cynical participants in a manner that acknowledges their own competencies while getting them to buy into the content as both realistic and valuable?

Second, who are the participants? Are they willing to get involved, to share their own experiences openly and honestly? How broad is their range of experiences? Are they all new to the role, in which case their inexperience may limit useful conversation, or are they all experienced to the point of weariness, in which case it may be difficult to persuade them of the value of active participation? Are there even enough attendees to have a meaningful discussion?

All these thoughts ran through my head while, bleary-eyed and half asleep, I sat on the early train to London. In the end, however, I need not have worried. Roman has worked in management and product roles for over 17 years, and has more than enough anecdotes and examples of real world application of the principles he espouses (both successes and failures) to demonstrate his bona fides. He cuts an imposing figure, part Steve Jobs, part “Gangs of New York” Daniel Day-Lewis, and delivers his material with confidence and mastery. I was particularly impressed with his method of starting with blank slides, then building them up with drawings and annotations as the exercises and discussions progressed. It seemed an excellent way to react to the queries of the attendees while maintaining a strong sense of narrative and interaction throughout the sessions, something that a set of pre-made slides or a handouts struggles to achieve. The approach reminded me greatly of similar techniques used in some YouTube videos (such as these), and I found it an excellent way of keeping an audience engaged*.

As for my fellow participants, an initial exercise revealed that we had a good mix of current, former, and new Product People in our midst. There were about 30 attendees in total, and remarkably some had even travelled from as far away as Germany and Slovakia to take part (and there was me thinking Yorkshire was far enough). Some, like me, came from small agencies, but many were based in start ups or large enterprises in industries ranging from fintech to engineering to travel and beyond. Most importantly, they were all happy and willing to share their experiences and ask insightful questions of our instructor and of each other.

Naturally, this being a course about Scrum roles, we began the course by building a backlog of questions we had about product ownership and goals we had for the two days. For myself, I really had two questions that I hoped the course would address. Firstly, and most applicable for my current situation, how do you leverage the value of product ownership in an agency that doesn’t have distinct Product Owner and Scrum Master roles? My second question was more personal, and takes me back to my thoughts at the beginning of this blog: that is, once a business reaches a certain size, or the scope of a product reaches a certain complexity, is it possible for a Product Owner to operate effectively in the Scrum sense of the role, rather than transitioning into “something else”?

Regarding Product Owners in agencies such as ours, Roman proposed two models, where either the client takes that role or the Project Manager (or someone similar in the agency) acts as a kind of ‘proxy’ Product Owner, switching hats as necessary for the duration of a project. While examining these possibilities, I thought about how we do things at Isotoma. With some clients, having someone on the customer side act as a Product Owner makes a tremendous amount of practical sense. They are a subject expert with a strong vision for the product that we’re developing, they are able to obtain buy-in from their business to support that kind of close working relationship, and they have a visibility of their internal business roadmap that allows them to prioritise work that returns the most immediate value. With other clients, however, that kind of relationship is a lot more challenging. Their schedule doesn’t allow them to devote the time necessary to a single product, their organisation doesn’t allow for them to ‘own’ the product themselves, or sometimes a lack of domain expertise means they rely a lot more on our input when considering what direction a product could take.

In practical terms, then, I realised that we actually practice both of these approaches. It’s not that one is intrinsically ‘better’ than the other, but rather each approach is more or less suitable depending on who our client is and what it is we’re building. Ideally this is something we can identify early on – much like my previous blog about asking questions (link), we use the Discovery phase of a project to determine the kind of role that our client is going to play in the delivery of the product. Are they able (and willing) to play this role effectively, or do we need to be more involved on a strategic level? This can change as the project develops, too, with some clients being heavily involved in the early stages and less involved once the product has started to take shape. Sometimes, when we’re acting more as direct partners, they will leave the early decision making to us and take more ownership of the product once its direction becomes more certain.

The importance for me, then, lies not in where the Product Owner role ‘sits’ during a project, but that everyone knows how decisions are made and buys into that process.

This brings me to my second question.

One of the main challenges that face Product Owners, in my view, lies in ensuring that they are understood to be Product Owners, rather than simply Project Managers working in an Agile environment. This is to say, their job is to own the vision of the product as well as its strategic and tactical direction. What their job should not be, in a true Scrum environment, is managing the development team on a day-to-day basis, or existing purely to triage requirements from other parts of the business without the authority to push back. Based on discussions with my fellow Product People over the two days, however, I think it’s fair to say that these experiences are fairly typical. Not one of the people I spoke to said “Oh, I wish I had less say in the direction that my product is taking”, or “I wish I had to spend more time dealing with issues arising during sprints”. Rather there was a real sense that Product Owners in large organisations are encumbered with an administrative burden that is anathema to the value that the role can bring. They become mini Project Managers, or funnels for business requirements from other stakeholders.

There is a standard model of how Scrum roles scale in large organisations. During one of the sessions Roman drew a distinction between ‘big’ Product Owners, who own the larger Vision and Strategy of the product, and ‘small’ Product Owners, who, typically through organisational design, have little influence beyond the Tactical level. This can work well, if everyone involved understands this role and works together as a kind of ‘Product Ownership Team’, but the broader challenge as the product and organisation grows is the dilution of a single point of ownership and subsequent weakening of both vision and consistency. If the product is simply too big by this stage, the question then becomes “Do we break down the ownership of this product into discreet ‘features’ or ‘components’, and if so what is a sane and sensible way of doing that while maintaining a coherent overall vision?”

It’s a hard problem to solve and I think, for my own part, it’s a problem that is addressed less by finding the ‘perfect’ configuration of roles and responsibilities in your organisational structure and more by individuals deciding for themselves whether they are truly satisfied with role that they are being asked to play. As Roman discussed in the course, when faced with a difficulty like this, you can either change what you’re doing or change how you feel about what you’re doing. I like this idea a lot, and would go further and rephrase it:

If you cannot take ownership of the product, take ownership of your relationship with the product.

And so I returned to York after two days, an officially certified Product Owner to go alongside the Scrum Master certification I achieved in 2016, and pondered the emphasis we put on methodology and roles and process management. Certainly we need all those things to maintain some semblance of order, to strive for value in the work that we do, to make sure that the things that need to get done are done by the right person in the right place at the right time. But still I wonder how many square pegs are out there, forcing themselves into round holes not because that is where they’re happiest, but because they’ve resigned themselves to never finding the square hole that would show them at their best.

* Note to self: steal this approach

Dan attended a two day course run by Roman Pichler. Visit to view course dates and learn more about Product Ownership.

The importance of asking the right questions

The management of a project is one of those situations where, when it’s done right, it barely looks like it’s happening at all. Requirements are gathered, work is done, outcomes are achieved, all with a cheery smile on our faces and a song in our hearts. Effective project management is built on a foundation of thorough planning, open communication, and disciplined adherence to mutually agreed processes.


Life is imperfect, projects are imperfect, and people are imperfect. Uncertainty is ever-present, change is inevitable, and the Rumsfeldian triangle of “known-knowns, known-unknowns, and unknown-unknowns” threaten us at every turn.

Luckily, I arrived into project management already well versed in the flawed nature of existence. This has meant my project management journey has been less about overcoming existential crises and far more about how, despite the relentless yoke of disappointment, we can still ensure projects are completed on time, on budget, and with minimal loss of life.

In my experience, the strongest weapon we have against projects going awry is honesty combined with a healthy supression of ego. Project management is usually seen as a problem of logistics and organisation, and I don’t doubt that this is a large part of it. However, my view is that managing the creation of complex digital products is, more than anything else, a problem of personal psychology.

What do I mean by this?

Our clients are experts in their own domains, whether it’s healthcare research or education funding or something else entirely. The first step in my being able to help them is to honestly explore what I don’t know about their domain, and work with them to fill in knowledge gaps that might otherwise lead to incorrect assumptions. In other words, I start the process by embracing my own ignorance and communicating that with our clients.

This approach is counter to a lot of day to day practices. If someone asks me a question, I generally think about what I do know, rather than what I don’t know. I am, after all, the product of an education system that typically awards points for regurgitating memorised facts over challenging received assumptions. I feel uncomfortable when I don’t know the answer to a question, because I have learned to associate this feeling with failure. When it comes to the sheer range of domains our clients cover, however, it is inevitable that I will bump up against the limits of my existing knowledge base on a regular basis.

It can feel risky to expose a lack of knowledge. Naturally I want a client to have confidence in me, and displaying a lack of domain-specific knowledge can feel counter to that goal. The biggest psychological hurdle to get over, then, is the acceptance that not knowing the answers at the beginning is a normal state to be in; embracing that it signifies opportunity rather than failure, and that the sooner we accept what we don’t know, the sooner we will be in a position to help our client achieve their goals. This is part of the reason we generally recommend a Discovery phase at the beginning of a project. It is during this period that we attack the Rumsfeldian triangle head on, embrace the things that we do not know, and build the foundation for the success of the project.

Encountering something new and unknown can be scary and intimidating.

This is ok.

In fact, this is more than ok – this is exactly what I love about managing projects at a company like Isotoma.

As a company we are experienced across a range of domains, and the knowledge does not all sit within one individual. We have a collective memory and level of expertise that allows us to meet the challenges that we face, an institutional memory of past problems and proven solutions. There will inevitably be times where we just don’t know enough about a domain to know the path forward instinctively, but by being honest about our limits and sharing a commitment to overcoming them, we grow as individuals and as a team.

It is tempting to think that we deliver great products because we always know the right thing to do, but I don’t think this is the case. In my view, we are good at what we do not because we always know the answers, but because we ask the right questions of our clients and of each other.

Photo by Josh Calabrese on Unsplash

Needs, Empathy, and Ghosts in the Machine: Reflections on Dot York 2017

Last Thursday I spent the day helping out at the hugely anticipated Dot York 2017 conference. It was an early start and a (very!) late finish, but I wouldn’t have missed it for anything.

The success of a conference lives or dies by the quality of the speakers, and this year the bar was raised yet again, ably compèred by Scott Hartop. Each talk provided enough food for thought to fill this blog a hundred times over, but I’ll restrict myself to discussing a few of my personal highlights from each session.

Adam Warburton changes our perceptions about competitors

The opening session of the day concerned User Experience and Needs. Adam Warburton, Head of Product at Co-op Digital, gave an illuminating demonstration of how seemingly unrelated products can end up as competitors when viewed through Maslow’s Hierarchy of Needs. Who would have thought, for instance, that online supermarket shopping and Uber are actually competitors within this framework, and how does this challenge the way we think about our own products? Adam went on to discuss how, by framing your business and the needs that you service in this way, you can force entire industries to transform for the better. The Co-op is not the most dominant supermarket chain in the UK, but Adam argues that their business goals have actually been met – by championing Fair Trade products and ethical business methods, they found that consumers valued these aspects of their business and so forced competitors to adopt their practices. For them, that was how they measured success.

Ian Worley speaks of getting stakeholder buy-in in a difficult environment

The second session, Business Before Lunch, saw four insightful talks from experts, innovators and entrepreneurs looking at the decisions we make and how we make the right choices for our own businesses. Ian Worley kicked us off with a talk about his time as Head of User Experience and Design at Morgan Stanley. Ian spoke with eloquence about achieving stakeholder buy-in by a) being brave about your expertise, and b) finding the right arguments for the right people. In the conservative world of banking, efficiency gains and improved bottom line were persuasive where aesthetic values and improved user experience were not. As Ian described his experiences, I thought about the broader question of value alignment: what do your clients value, what do you value, and what do you do if you can’t find common ground? At Isotoma I am fortunate to work with a broad range of clients, some offering exciting technical challenges, others that provide opportunities to do real social good. Very few of us in this industry can fully separate our work identities from our personal ones, so the importance of doing work with clients who share at least some of your values cannot be overstated.

Hannah Nickin’s talk highlighted for me how destroying capitalism isn’t just a slogan..

Following quite the best conference lunch I’ve ever had (with many thanks to Smokin Blues!), we heard four presentations on Building Better Teams, with Hannah Nicklin providing a dramatic reading of her ethnographic experiences amongst games development collectives. Hannah’s talk highlighted for me how destroying capitalism isn’t just a slogan, but a praxis – the intersection of place and behaviour where we challenge orthodoxies. We probably can’t overthrow systems of exploitation overnight, but we can problematise convention and test alternatives. As a business, Isotoma works hard on cultivating an environment that works for its employees, and not simply operating as an entity for converting labour into ‘stuff’. What works for you may not work for me, and that’s ok, but the crucial thing is to challenge the received assumptions of what your business is for, and the value that it brings to the world.

Natalie Kane talks about how easily human bias can creep into development of advanced software

We rounded out the day’s events with a panel on Being Human, with an emphasis on empathy, self-care, and our responsibility towards others. Natalie Kane, the Curator of Digital Design at the Victoria and Albert Museum, delivered an intriguing talk concerning so-called ‘ghosts in the machine’, and how easy it is for the advance of technology to be embraced, unchallenged, as an unimpeachable good. Our ethical obligations do not begin and end with our good intentions, she announced, but require our constant and active engagement. Natalie argued that such ‘ghosts’ serve as a reminder that technology is not neutral, and we have a responsibility to keep a critical stance towards technology and how we use it. To paraphrase Jurassic Park, just because we can doesn’t mean we should.

I cannot wait to see who we book next year!