What is a Clerk?
The Clerk is your personal waiter for all your user story serving. Gathering all the wishes, user stories and demands is what The Clerk does. (S)he isn’t focussed on achieving the product vision, nor on crafting clear goals and objectives and the Clerk most certainly never says ‘no’ to stakeholders. There’s nothing wrong with servant leading your customers and stakeholders as a Product Owner, but if your main purpose during the day is getting new ‘orders’ from stakeholders… then you’re missing the point of being a great Product Owner.
A clerk is a white-collar worker who conducts general office tasks, or a worker who performs similar sales-related tasks in a retail environment (a retail clerk). The responsibilities of clerical workers commonly include record keeping, filing, staffing service counters, screening solicitors, and other administrative tasks.
— Wikipedia, Oktober 2019 —
The Clerk is also referred to as the admin, secretary, waiter, yes man or order taker.
The Product Owner as a Clerk
With the many Product Owners and Product Managers we have trained and coached in their daily practice, we’ve observed the following patterns in Product Owners that we would classify as Clerks:
- The Clerk tends to have (endlessly) long Product Backlogs, which is mainly caused by the fact that (s)he rarely (never) says ‘no’ to the stakeholders. A typical response from a Clerk when someone (a stakeholder) poses an idea, requests a new feature, or tells them what to do, they’ll respond: “Sure, let me add that to the Backlog.”
- The Clerk typically has an internal focus. Internal stakeholders typically tell them what to do and what to build. Clerks typically don’t interact with external stakeholders, rarely with external users, and (almost) never with real, paying customers who actually buy the product. Clerks are also rarely talking (or allowed to talk) to external influencers or governance stakeholders, such as legal authorities and/or regulators.
- Other associated behaviors with the Clerk type of Product Owner are: acting as a go-between (carrier pigeon) between the Developers and the stakeholders, not taking any decisions eventually being a demotivator for everyone, no ability to say no, trying to please everybody, being a micromanager, distributing tasks amongst team members, managing via spreadsheets, being a people utilizer, reducing effort estimates by the Developers, maximizing output and being a team coordinator.
The results/effects of acting like a Clerk
Obviously, not all (Product Owner) Clerks are the same, and not all the results/effects may be visible in your context. That being said though, what we typically observe when Product Owners act like Clerks is:
- The Product Backlog may contain hundreds of items, that were added to it, without talking about the why, the value, the opportunities in the market, etc. It’s just an unmanageable, endless list of user stories;
- You aren’t building a product based on a vision, you’re just delivering what everybody wants from their perspective. No great product has ever been built by a committee of stakeholders;
- Focus on short term results;
- Little to none focus on long term outcomes (TCO, ROI, P&L, etc);
- You are slowing the Scrum Team down;
- The Scrum Team isn’t learning and obtaining more business, domain, customer, and product knowledge. This prevents them from making better, faster, and more informed decisions and herewith increase self-organization;
- The Scrum Team isn’t learning to be self-managing their own work, they won’t be taking ownership (over planning, results, quality, etc), and controlling everything will cost you a lot more work and time yourself (which you can’t spend on more important things);
What you can do to move away from this stance
As mentioned earlier in this post, servant leadership is important for every organization, however, it is about servant leadership, not about being a servant (or clerk, as we like to call them). So, what can you do to move away from the misunderstood Clerk stance?
Well, one thing you could do is to stop being the carrier pigeon between the stakeholders and the Developers. Instead, have them talk to each other! Let stakeholders explain the requirements to the Developers directly. And let the Developers interact, ask for feedback, and test stuff directly with stakeholders, customers, and users.
Also, stop saying ‘yes’ to everything. Create some kind of a plan for your product or service. Define your own vision and goals. And start explaining them to people. Ask for their feedback and input. See if you can come to a shared understanding perhaps? And, oh and this is important, try to focus your vision, goals, and feedback to the outside world! Make it all about customers and users. So get out of the safe environment of your office, and start talking to your real, paying customers!
Want to learn more?
This is a blog from the Stances of the Product Owner series, in which Professional Scrum Product Owner Trainers and Consultants Chris Lukassen and Robbin Schuurman explore preferred and misunderstood stances (attitudes) of Product Owners and (Agile) Product Managers. Read more about the Stances of the Product Owner on this page.
Go experience the Stances of the Product Owner!
If you’re a Product Owner, Product Manager, Scrum Master or Agile Coach with about a year (or more) of experience under your belt, go and explore the Stances of the Product Owner in the Professional Scrum Product Owner-Advanced class. Find a trainer to your liking or in your area, and deepen and expand your Product Management knowledge and skills. And let us know what you think about the training! What did you like? What can be improved? Let’s collaborate to take the profession of Product Ownership to the next level.
If you’d like to experience the all-new Professional Scrum Product Owner-Advanced class, go to Scrum.org to find a class in your area. If you’d like to participate in one of our classes, check out our Xebia Academy page for more information or inquire for an in-house class via training@xebia.com.
