When development resembles the ageing of wine


, , , , ,

Once upon a time I was asked to help out a software product company.  The management briefing went something like this: “We need you to increase productivity, the guys in development seem to be unable to ship anything! and if they do ship something it’s only a fraction of what we expected”.

And so the story begins. Now there are many ways how we can improve the teams outcome and its output (the first matters more), but it always starts with observing what they do today and trying to figure out why.

It turns out that requests from the business were treated like a good wine, and were allowed to “age”, in the oak barrel that was called Jira. Not so much to add flavour in the form of details, requirements, designs, non functional requirements or acceptance criteria, but mainly to see if the priority of this request would remain stable over a period of time.

In the days that followed I participated in the “Change Control Board” and saw what he meant. Management would change priorities on the fly and make swift decisions on requirements that would take weeks to implement. To stay in vinotology terms, wine was poured in and out the barrels at such a rate that it bore more resemblance to a blender than to the art of wine making.

Though management was happy to learn I had unearthed to root cause to their problem, they were less pleased to learn that they themselves were responsible.  The Agile world created the Product Owner role for this, and it turned out that this is hat, that can only be worn by a single person.

Once we funnelled all the requests through a single person, both responsible for the success of the product and for the development, we saw a big change. Not only did the business got a reliable sparring partner, but the development team had a single voice when it came to setting the priorities. Once the team starting finishing what they started we started shipping at regular intervals, with features that we all had committed to.

Of course it did not take away the dynamics of the business, but it allowed us to deliver, and become reliable in how and when we responded to change. Perhaps not the most aged wine, but enough to delight our customers and learn what we should put in our barrel for the next round.

Be a Great Product Leader


People who know me professionally know that I’m passionate about Product Management.  I truly believe that, done properly, a strong product leader acts as a force multiplier that can help a cross-functional team of great technologies and designers do their best work.

Unfortunately, the job description of a product manager tends to either be overly vague (you are responsible for the product) or overly specific (you write product specifications).  Neither, as it turns out, is it effective in helping people become great product managers.

I’ve spent a lot of time trying to figure out a way to communicate the value of a product manager in a way that both transparently tells cross-functional partners what they should expect (or demand) from their product leaders, and also communicates to new product managers what the actual expectations of their job are.  Over the years, I reduced that communication to just three sets of…

View original post 880 more words

The mythical Product Owner


, ,


“He’s just there”, Jeff Sutherland replied to the question where we could find this mythical person. Balancing between business and technology, having the vision and the time to guide the team but also go out there and meet the users, empowered by the business, the one “where the buck stops”, yet with technical knowledge to understand the developers needs. Sometimes it’s easier to spot mythical creatures than true Product Owners.

Over the years I have seen very few persons embodying all these properties, but those I’ve met learned me what to look for. Gave me a reference model so to say. But the best Product Owners I’ve met, all failed this omnipotent description, but rather had built a team around themselves that compensated for their weaknesses.

So rather than having a single Product Owner, you would have a team that acts as Product Owner, a team in which you typically find: Business Analysts, Product Managers, Project Managers, Designers or Release Managers.

And what do they do? well they all have their specific competences, but the focus of the Product Management team should be the business value. What will a feature cost and what is its return on investment, how do we measure this? How does it fit in the overall picture? The problem invariably becomes how to align these people and have them talk with one voice to the team.

More overhead? Yes. Necessary given the complexity of the task? Yes again. We can insist on a single product owner, but in many cases, we’ll fail, and the committee of Product Owners provides a workable solution.

P.S. be careful with committees: “a camel is a horse defined by a committee”


iOS is catholic, Android is protestant?

Lukassen's Blog

Stained glass at St John the Baptist's Anglica...

Freely after the article: “The Holy War: Mac vs. DOS” By Umberto Eco, September 30, 1994:

Friends, blog visitors, countrymen, I ask that a Committee for Public Health be set up, whose task would be to censor (by violent means, if necessary) discussion of the following topics in the internet Each censored topic is followed by an alternative in brackets which is just as futile, but rich with the potential for polemic.

View original post 524 more words