The most effective Product Owner I have ever worked with did not have that title. I mention this at the outset of the post merely to say that titles don't really matter that much. What matters is the role itself and organizational empowerment to do the job right.
You have a Product Owner because you want to go fast and develop great software. If you don't have one you are making the choice to go slow, which is always a bad idea. You may develop great software anyway, but it will take longer than it needs to.
The product owner is a critical role in modern software development. The Product Owner’s role is to supply the following to the development team:
Effective Product Owners work with stakeholders (usually customers, executives, business decision makers, and visionaries) to supply an effective workstream for their projects. Very often good Product Owners are neither the visionary nor an executive, but are someone with the ability to manage those people and the guts to make decisions about the product.
Ineffective product owners are too busy doing other things to be bothered with the day-to-day decision making of the team and leave questions unanswered for long periods of time, delaying the work.
Effective product owners manage and participate effectively in two work cycles:
The Development Sprint Cycle (usually 2–3 weeks) A good Product Owner makes time to attend important meetings and answer questions for the team doing the work.
The Product Development Backlog Cycle – A good product owner is constantly working with business stakeholders and customers (end-user customers) to understand what is working and what isn’t.
Ineffective Product Owners don’t spend the time necessary to get their product backlog prepared. This leaves their teams unable to plan or estimate work – delaying progress, de-motivating their teams, and creating blind spots in cost and timeline for their projects.
Effective product owners work hard to understand their competitors and customers, they know their place in the industry and where they are trying to go. Being an effective Product Owner is typically a full-time position, I seldom sees a product owner that can handle owning more than 1 product, and I have never seen one able to effectively handle more than 3.
I learned a lot about how to do the expectations for the role of product ownership, and lots of techniques and processes for how to do the job effectively. The class was very engaging with a good mix of instructor-led content and group activities.
One of the most significant aspects of being a Product Owner in scrum is making decisions and prioritizing work.
Here are some things that will make it difficult to do the job effectively:
You aren't given the authority by your organization to make decisions for the product.
You don't give yourself the authority to make those decisions.
You have a hard time making any decisions.
Number 1 on the list is something that you can do something about, and we spent time in the class discussing it.
If you are undercut by superiors or colleagues, you need to address that with the superiors and colleagues. Often times they may not be aware of it, in which case simply brining it up is enough to make a difference.
In other situations you may need to understand the why of the situation and seek to improve your understanding of the business or your boss vision. Then when you are on the same page you will have less conflict and less decisions that have to be revisited.
If the your boss, colleagues, or team leadership fundamentally doesn't trust you or anyone to make those decisions - seek alternative employment.
Similar things apply here. If you believe that you can be an effective product owner and make the necessary decisions based solely on data, abstract principles, and rational thinking, you will run into problems. You will never have enough data to make all the decisions you have to make NOW.
You can have the data in 3 months, but the world may have passed you by then.
An effective Product Owner is going to Know a Lot - they will know the domain, they will know the analytics, they will know the users (some of them personally). They will use all of these things to make decisions.
But they won't (and can't) know everything. Even if you could know everything today, you wouldn't know everything tomorrow.
And when you don't know everything, you will have to make decisions in the absence of data. In these situations, you need to know your instincts and trust your insight to guide you.
And trusting your gut means listening to and understanding emotions - and being able to defend that decision. Whether you call it trusting your gut or rapid cognition you will need some of it to be an effective product owner.
If you aren't used to working this way, then you can choose to focus on the activities that will make your insights and intuitions more informed - learn things, focus on data, know as much as you possibly can.
Then when you need to make a judgement call, you will have a solid foundation that you have built upon to get there.
But when the time comes, you will need to decide in the absence of data, and you may have to argue your point, so be ready to put some feeling into the discussion and push for what you think is the right answer.
When you find yourself in such a situation, the best and easiest way to handle this is to recognize that this is the situation are in: You don't have enough data, you will need to make a recommendation and push for what you think is right.
I find that simply acknowledging the situation as such - whether externally, internally, or both - is very helpful.
It is also helpful to remember in these situations that most bosses want someone who will make a strong recommendation and push for what they think is the right answer.
They will see you as providing decisive leadership and be able to back you up in your recommendation, without needing to get deeply involved in the data, details, or weeds. You are smart and well-informed, it's your decision to make as the product owner.
If you run into headwinds here then the same recommendation applies as above: seek to understand those headwinds, adjust if necessary, continue making recommendations based on the best data available.
You may be wrong.
We're all wrong sometimes.
Being wrong is an opportunity for further introspection and learning. Accept it as such, make further adjustments and move on.
I've written in the past about the emotional rollercoaster and how you should think about it for the purposes of productivity and team building.
I got this basic picture from Dr. Alan Watkins in his book Coherence. It is based on the emotional range that we experience during any change, based originally on the stages of grief. For the record, the negative emotions laid out by Dr. Watkins are:
Denial (at the top left)
Despair (at the bottom)
Yikes. Yes, those are the negative emotions we experience during change.
Another way that this impacts organizations is that leaders often become extremely adept at handling these emotions in themselves, and this presents two risks:
The first risk is that the leader can be in a very different place on this roller coaster than where there fellow employees are. Leaders often get advance notice and have more time to process. They also may have more experience dealing with change all across their organization.
Employees with less flux in their day-to-day duties may not be used to riding this roller coaster, and so the leader struggles not only to understand why someone isn't already on the right hand side, going up, they miss that the struggle is there at all.
The key tool to avoiding this pitfall is awareness. Are there big changes going on? Expect that everyone is somewhere on this continuum. Talk about it. Ask questions, don't accept "I'm fine" as an answer. People may be coping, people may be struggling, people may actually be fine.
But as a leader you need to know for sure and it may be that someone who is really on the right hand side has some insights that could benefit you or someone else. For this reason alone, don't accept "fine", even if they're fine.
The second challenge is that leaders can believe that they are so good at this that it doesn't apply to them. They may believe that they don't feel the negative emotions or that they know how to speed through the emotions on the left quickly. They probably can do this for small or medium sized changes.
Leaders often thrive on change - this is certainly the mold that our culture has laid out for us.
But what happens when the change is large, unexpected, or drastic? What happens if you aren't used to processing the negative, left-side emotions? What happens if you've become so accepting of the leadership norms of change that the negative emotions are unfamiliar territory.
Today's norms say you can't be afraid, desperate, or angry about change. You can't be anxious, frustrated, or in denial. You certainly can't feel despair. You need to understand and move to acceptance quickly. How else will we lead others effectively?
But things happen. Some times a change seems personal. Some times a change is personal. Sometimes a change originates in the personal sphere and comes crashing into the professional. Sometimes we end up on the left half of this roller coaster, going down, and we don't have the ability to simply fast forward through it.
When this happens we need to accept in ourselves that there is a probably a reason and look for it. It may be that a trusted friend can help, it may be something that you do on your own.
If you are stuck (just as employees, peers, and bosses often get stuck) this is not wrong. This is something that can help you go higher and achieve more when you understand it, work through it, and get yourself on the right hand side, going up.
What's most important is to not let your normal adaptability and capability force you into believing you're somewhere you're not. Leaders ignore their own emotions on the left-hand side at their own peril. You're likely to come off inauthentic and fail to help others on their own journeys if you automatically skip ahead to the right.
This lack of self-awareness can lead to lashing out or feeling disconnected. If you are angry or disconnected people will assume even more negative things about the change. At best this means they will think you are an inauthentic jerk. At worst this means that they'll think you're hiding something, which, in a way, you are.
They will make their own guesses about what you're hiding. Usually what they assume or gossip about will be worse than your own struggles with a big change.
Amazon has recently opened up some of its internal AI education resources for anyone who wants to use them. They're freely available on its learning platform, which you can use if you have an Amazon account.
I'm currently working through the Machine Learning for Business Challenges course, which has some great content. It's available here:
When software developers are focused on good design - focused on taking the time to build a system the right way - they are focused on delivering business value for their customers or stakeholders.
They want good design because they know that in the medium and long term a system with good design is easier to support and extend. This has clear business value - you can do more new stuff (features) for less money and you can fix problems (bugs) for less money.
More stuff for less money is good business value. In this way technical value (good design and elegant coding) is business value.
A system with poor design may get more features built more quickly, but before long the productivity will break down as the absence of plan results in fragmentation and chaos.
So in this way, you may get a quick hit of productivity, but in the long term you spend much more to get less which is bad.
There are times in every project where you reach an inflection point and what I described above needs to invert, temporarily. See this earlier article on the topic of technical debt and why sometimes the two can be at odds.
During the inversion, you take on technical debt to deliver some quick hits, once the underpinnings and architecture are in place, so that you can ship a product on time to the marketplace.
Overall I think it is important to remember that the title of this article is true - in the long term good design is business value. Though sometimes you suspend that temporarily to deliver.
Sometimes business people want results right now and impatience with delivery is seen as a virtue. It can be. If it is a temporary inversion, and not a long term state of affairs.
It can be a real hindrance to long term value if that state of affairs is chronic and without respite.
The decision to switch from the long term view (important at the outset and through most of the life of a project) to the short term view (often important at the end of the project, to deliver on time) is an emotional one.
People don't want to stop designing and they don't like the idea of taking on technical debt. However, it can't be avoided.
Your job as a software development leader is to listen and guide your team through this transition, AND to guide the business back, once the release is done.
Be aware of the emotions and motivations on both sides. Make the smart decision to ship. Also, make the smart decision to switch back and pay your technical debt when the next phase begins.
I think that we need to recognize two important things:
A request to finish fast and on a time line can feel arbitrary to people you need to articulate why.
A request to finish fast and take on technical debt can also appear to be a request to stop delivering business value and do a shoddy job, you should avoid phrasing things so that it sounds this way.
A choice to finish fast is a choice for the business value of now versus the business value of later which can be called many things: time value of money, a bird in the hand is worth two in the bush, or "we need to close this account". This can be a good and smart decision, but it is a decision with trade offs. Acknowledge the trade offs and press forward.
The placebo effect isn't something I think about very often and when I do it is usually in the context of dismissing it as a trick of the mind or something like that. Maybe the placebo effect is just someone getting better on their own where it would have happened anyway, with no medical intervention at all.
I suspect a lot of us think this way.
But there are people out there wondering why it's happening. Why does the body sometimes heal itself? Can we understand it? What mechanisms are at work? If it is a trick of the mind, why does it seem to happen so consistently?
For a long time, nearly 250 years, we've known about the placebo effect, but we have done very little to study it.
That is changing now.
Experiments are focused on understanding how the placebo effect works, in the hopes of understanding it and putting it to work for the betterment of man kind.
It's a fasciating article and you should read the whole thing.
There are two parts of this article that interesting as leadership examples, and I want to take a few minutes to talk about those.
The origin of our understanding of the Pacebo effect come from 18th century France and involves a famous American.
Benjamin Franklin was part of a panel that was tasked with analyzing the work of the mesermist Charles d’Eslon. Mesmerists (disciples of Anton Mesmer) claimed to heal people of chronic illnesses and pain using a force called Animal Magnetism.
The panel developed experiments where the patients cannot see d'Eslon, thereby separating the effects of the mesmerist from what the patient might be supplying themselves. In doing so, the panel creates the first blind medical experiments and isolated the placebo effect.
The results of the experiment were quite clear: something besides animal magnetism, something the patient's themselves are supplying, is producing the effects of the treatment.
Having been told that imagination produces the effects attributed to his work as a mesmerist, d'Eslon responds:
the imagination thus directed to the relief of suffering humanity would be a most valuable means in the hands of the medical profession.
I find d'Eslon's reaction remarkable as an example of leadership.
I have seen people go to great lengths defending things not very integral to their livelihood and profession. How many times have you seen people defend turf for the sake of defending turf and maintaining the status quo?
D'Eslon, whose career is on the line, responds very differently.
Imagine being told you're a fraud and instead of reacting with hostility, you analyze the data and retrieve the key insight. Instead of defensiveness, instead of anger you simnply extract that conclusion your detractors seemed to have overlooked.
I've seen some people who are cool under pressure, but I've never seen anything like that. It should probably go in the record books under, Most Reasonable, Self-Aware Reaction Too Bad News, Ever.
I'm not sure what happened to d'Eslon after that. But I'd curious to know what such a man did with the rest of his life.
Imagine seeing your work discredited in public and responding with a valuable insight.
He saw the value in the placebo effect and applying our imaginations to relieve suffering.
The second thing that I think we should think about as leaders:
Some pretty brave people applying imagination to something that had been dismissed by medical science for nearly 250 years. As the article mentions, this isn't an easy journey for them. To take a topic that has been dismissed for that long and try to get people to pay attention to it is a pretty amazing feat. There are a lot of detractors, but they think it is important so they are dong it anyway.
We should take a lesson from the strength of people when confronted with challenge - Do we persevere when people question us? Or do we press on?
Those studying the placebo effect are pressing on because they believe there is something valuable and interesting, that medical science can finally come to grips with.
I'm glad that now there are those in the medical profession paying attention to how the placebo effect might be used differently and I'm glad we have the tools so that we can begin to understand it. New tools (DNA sequencing and MRIs are mentioned specifically) give these researchers the ability to peer inside us and look deeper than we ever could before.
But while the technical frontier that has opened, the frontier of human complacency, tradition, and established opinion must still be confronted and there is no new tool for that. There is only courage and perseverance, just as there always has been.
These are both great examples of human beings facing the challenge of change - one story of someone faced with a challenge/change and reacting with equanimity and grace, and one story of those taking on the establishment because of what they believe is the right thing to do.
Both of these are worth thinking about as examples of how to face challenges and show leadership during times of change.