7 lessons from 5 years of being a Product Owner
1. You can’t over communicate
The three main skills of product ownership are stakeholder management, communication and product vision and experience (hard skills). Roughly, two third of what you do is communication. If you are not tired of repeating the team’s goals, the vision of explaining every feature in each of its details, you did not communicate enough. The basis of education is repetition, so do it as much as needed. Talk to everyone, in one on ones and in ceremonies. Make sure to get the temperature of everyone, see how they feel in the team, what their individual goals are.
Then start laying out the fundamentals of your vision. As a PO, you know the business side and the users better than anyone in your team, and they need to know too. Create ad hoc workshops for your team and your stakeholders, and share your knowledge and your work best practices on a regular basis. As the main project manager on board, you are responsible to make everyone accountable for their results, and understand why these results matter to everyone.
Communication is never done.
- You are never done learning new elements which feed your long term vision
- You are never done releasing new features which your users should know about.
- You are never done coming up with new ideas.
Find the correct spaces to communicate with each one of your stakeholders. Make sure they all have the knowledge required to understand and agree with your decisions.
2. Writing a ticket is not being a product owner
Pushing tickets in a backlog is a monkey job. That’s the easy part of product ownership. Good product people are extremely careful about what they add in the backlog. They communicate around it, get their engineers and users feedback several times in consideration, prepare the next phases, and make sure there are no unknown left when it goes into the sprint, on the kanban board. A well known consequence of being too liberal with what goes in the backlog is its tendency to grow beyond normal proportions (endless backlog groomings, anyone?). Be hard on yourself when writing tickets, and limit the amount of elements in your backlog to the minimum to keep it clean and move fast.
3. Your OKRs only matter to you
Instead, discuss your main problem statements with the team. Share the ownership of the problem. Get everybody on board with the long term vision you have elaborated. Share your goals. Be open about everything you want to do. Seek feedback from every team member. And once you have a good feel for what people want, and what the business goals are, you can start making balanced judgement calls in your priorities, and get a set of objectives the team will stick to and recognise as its own.
That is, until you have completely shared the ownership of the results with the team, and the team is collectively responsible for achieving goals set together. The focus and performance of your team depends entirely on your ability to steer the ship in the correct direction. If you come to a team with a set of goals set by top management and none of them remotely matters to your team, you will spend 6 months swimming up stream and fighting to get anything done. Great recipe for burn out.
4. Until people say “we”, you don’t have a team
No one in a product team should say “me”, “you”, “they”. The only acceptable word is “we”, as in “we fucked up last sprint because we overcommitted”. It kills finger pointing and politics in one elegant move. It forces people to work as a unit and help each other. As I don’t know who pointed out, the only real failure which is unacceptable in a team is not failure to achieve results, it is the failure to ask for help. When people only think in terms of “we”, they are naturally inclined to help or seek help. One of the most striking examples of this kind of leadership is David Marquet, whose lectures I can highly recommend.
5. Forget about your framework
Most agile certified training are a scam designed to steal money from rich companies to put it in the pocket of the scrum alliance. Their collective power can be summed up in two words: “Experience” and “Network”. But that being said, the most important point here is: don’t be anal with your story points, stand ups, estimates, cycle time and other cool sounding agile buzz words. What matters is your team’s system, and how well the communication between people flows. Seek high alignment, high engagement and it will work, regardless of the framework. Without these two, you can forget about any type of ceremonies, mostly the retrospectives. Retros are only good if people are openly communicating, and if your team doesn’t do that, you’re not getting anything out of a hundred retros.
Make sure every team member is valued for their strength, and can openly talk about any topic. One of my favourite techniques is to always ask for the opinion of the person with the least experience first, so as to get everyone’s ideas out in the open before a senior tries to impose their solution. Another is to get the person with the softest voice to speak their mind often. People have to pay a lot of attention to not overpower someone speaking in a soft voice, forcing respect and understanding in the meetings.
Focus on the well being of the people and their happiness, and decide later on what framework you want that matches people, goals, and the project you work on.
6. Ideas are easy. Execution is everything.
This one goes out to John Doerr. If I had a dollar each time I heard a billion dollar idea around me, I’d be a millionaire. That being said, I know exactly 0 billionaires, so somewhere in the process all of these great ideas got lost for everyone.
There is a big difference between an idea and a plan, and an even greater between a plan and a live product or product increment. The one thing that separates good from great in product ownership is the ability to deliver consistently against your objectives. As Steven Covey (7 habits of highly effective people) puts it, “the main thing is to keep the main thing the main thing”. I can’t even stress enough the importance of this one. Stakeholders will have great ideas. You will. Your team will. Users will have amazing ideas. Even your mom will come up with great stuff. But you can only build one at a time, so which should it be?
Focus on the one idea with the highest leverage, and throw everything else in the bin. Do not waste time on anything which is not your goal. Bad product owners say yes a lot. Great product owners rarely say yes, and the people they work with are surprisingly fine with it.
7. Done is better than perfect
How many times have I thought about a new feature and stared at my computer, helplessly trying to come up with that perfect solution which would work for everyone, all the time, and be simple to build? Not sure, but one thing I know is I am not doing that ever again. It never works. The only things that work are pragmatic, user focused, SIMPLE solutions (massive emphasis on simple).
Interview your developers, your users, write down the simplest piece of the puzzle which gets you to the next piece, and never stop working. Prepare big time chunks in your week to focus on your feature development and nothing else. And as soon as your first requirement document draft is ready, seek feedback from stakeholders, users or developers.
The best features are always a cooperation between your teammates, good data and assumptions, and a well framed user problem. You can’t let your team wait weeks for your specs, so make sure you improve them fast and get them onboard as early as possible in the process. Ideally they even help you figure out what would work best for the users, but that applies to advanced teams.
And as soon as you have requirements for a first feature that can
be put in production, do it. Do not over think it and do not wait weeks from
the moment the requirements are ready to start building it. This is waste in
your system, since resources sit idle for a time before being put to use.
Better have requirements just in time so they go in production, and work Just