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.
I'd go so far as to say, I'm going to expect developers I work with to read it and tell me which kind of technical debt they're talking about.
You should take the time to read the whole article. It's great. I'm not going to summarize it, only talk about a couple of things that I think are valuable and interesting.
Here's the quadrants for technical debt as Fowler defines them:
The first part of the article discusses the concept of technical debt and how it works as a metaphor to financial debt. Largely this distinguishes the concept of prudent from reckless debt, which is a useful distinction to have on hand for discussing projects with developers and clients.
In the financial realm you have prudent debts that you take on carefully, after doing your research, in order to further your goals. Buying a home, buying a car, purchasing rental property.
And then you have reckless debt that is taken on without proper research or out of alignment with your goals like buying a luxury items you can't afford.
There are two parts of this that I want to talk about in a bit more depth.
The first piece has to do with the concept of prudent, deliberate debt and where we begin taking it on in a project. I've had many conversations with developers over the years who may struggle to shift their mindset as you reach the end stages of a project.
Developers like to do things the right way - the scalable way, the smart way, the most effective way. I certainly did when I was a developer, and all the good developers I've known share this characteristic.
But there are times when you just need to finish off a feature or two and launch a product. Delays are dangerous in this situation. This is the moment to switch from avoiding all debt to taking on prudent, deliberate debt. It's time to say, "Yes, we could design it that way, but we need these features and we need to go to QA next week so please get it done."
Business realities drive us to these decisions, and most importantly, it is not wrong to do this. If you were a very savvy PM or product owner you might even put a date on the calendar when you think the decision making may change.
This doesn't negate the value of the all the design and hard work that went before it, nor does it mean you can't go back and revisit these items in the future. It just means, right now, in this phase of the project, we are making pragmatic decisions to ship and that is 100% OK and in line with best practices.
The second is the concept of prudent, inadvertent debt. Every project has it. No good developers are ever really satisfied as a result of it. But we can't ever truly get rid of it.
Why is that?
Just for clarification: prudent, inadvertent technical debt is the idea that some parts of system design will only really be apparent after the project is complete or once a particular phase is too far along to alter them.
This concept has no analog in the financial debt metaphor. There isn't a financial debt you can take on inadvertently and still be prudent. Being prudent implies that you don't have inadvertent financial debts.
But software is not finance - every software project has things that the development team would like to refactor toward the end.
If every project has this type of technical debt, why can't we eliminate it?
We can't eliminate it for two reasons:
Technology changes too quickly. New tools come along and those tools have real business value so they can't be ignored. We bring them in to projects knowing we don't have every design ready for them. We do this because we push for ever greater scale, effectiveness, and feature delivery. We do it knowing it results in imperfect designs.
Business Spaces are too diverse and changing too rapidly. Just when we think we understand an audience or a business, it changes. You can't be complacent, you can't rest thinking you know everything, you don't. Neither can you be paralyzed by such knowledge.
So, when you mix 1 and 2 together you get a situation where you can't design everything in advance. You look at the past, look at what you've done wrong and right, look at what you know about the tools you're using. And then you take the leap. You know you will taken on prudent, inadvertent debt by doing so.
The best bosses and clients understand this. It's why we like working for them and why work hard to eliminate everything else and build the great products we're capable of building.