Continue reading in our blog
You’ve started a web project. Congrats! This means you (or your colleague) will inevitably become a Product Owner: even if the title is not spoken aloud, you’ll have to do the work.
This post is our message of advice: from us (Developers) to You, our future App Holder (no matter if you’re professional or beginner).
Why are we writing this post?
To make life easier for both of us: Product Owners and Product Creators.To break the wall between people who know what to do and people who know how to do it.
For you to enjoy developing your app with us, we’re sharing this priceless advice. It accumulates the pain and wisdom of years of work.
“Objection! Nothing valuable comes for free!” you may say. Right. We have our interest: to let Product Owners know the critical attitude we expect from them. This will make our life happier.
Some basic notions
Before we get to the core, let’s sync our understandings of a Product Holder role in Agile development process. Otherwise, we might be talking about different people and responsibilities.
That’s the first secret unveiled: a Product Owner is absolutely not a Project Manager!
Who is a Product Owner?
The person who knows Product the best, believes in it, and drives others.
A Product Owner is a person with the Product Vision. It means knowing:
- what the Product will do (with smallest details)
- what problems will it solve, and
- for whom
Whenever there’s a question about the Product — a Product Owner always has an answer.
At the same time, a Product Owner is a Leader who:
- Sees the direction for building the Product
- Knows the result to be achieved
- Motivates the team with belief, drive, and enthusiasm
As a consequence of that total product knowledge, a Product Owner acts like a Proxy (Connector) between the Stakeholders and Developers, coordinating Product wishes and capacities of the Development Team.
What does a Product Owner do?
Product Vision: becomes the Knowledge Keeper for the Product. What’s vital: knowing what the product is and what it’s not are equally important!
The instruments for putting down this Vision are Product Roadmap (the plan with the business goals and technologies, used for achieving them) and Product Pipeline (the list of Products, sold/developed by a company, often — in different stages of Scrum development/production).
Product Backlog: gathers new features the future Product must have, maintains and prioritizes that knowledge base.
The core competence here is estimating the Business Value of these functionalities, and thus prioritize the Backlog, answering the question “What gives us more business value with less efforts/expenses?”
User Stories: writes documents that explain to Developers:
- Why the new feature is needed, and
- Expectations after the feature is implemented (these may appear in Acceptance Criteria)
The document is usually a detailed one and contains usage examples, screenshots, mockups, and other things that make explanations easier.
We’ll cover the art of writing cool user stories in a separate blog post.
Sprint and Release Planning:
- Decides which features must be done in the next development cycle (Sprint), and thus — which functionalities have to be postponed and done later.
- Make sure these features are fully functional in the last stable version of the Product (Release).
Coordination of Development Team’s Work: participates in:
- Working meetings with Developers (Stand Up/Scrum meetings)
- Discussions of new user stories for the upcoming sprint (Sprint Grooming)
- Follow-up discussions on what was good and went wrong during the completed sprint (Retrospective Meeting).
Collaboration: connects Developers and Stakeholders on all possible issues. This is exactly where the famous motto of Agile Manifesto, “Individuals and interactions over processes and tools”, is applied the best.
Although not absolutely complete, this list includes the key responsibilities of a Product Owner.
So what’s the advice?!
BE AVAILABLE
… to answer questions
Developers always have questions. Hundreds of them. The sad graph of interdependence states: the less details a User Story has, the more questions arise during the work.
Surprisingly, it’s good for you: questions show that Developers care about your product, trying to foresee problems and make it better.
This leads to a ground-breaking notion. Remember: Developers are on your side!
Try to answer questions as soon as you can. Make you teammates sure you’re always near to support them with all the info you have. Then, they’ll be sure to be moving in a right direction, and all the words in the world won’t express how important that is.
… to discuss
Developer’s think and plan before they start — it’s a part of their mentality. Thus, they may foresee issues before they appear. Being open for discussions and proposals may save days (!) of work and billions of nerve cells.
… to give feedback
Say what you don’t like. Share concerns. Ask questions yourself. Anything to let Developers know how do you feel about their work.
Web development is a two-way road. As a family, it needs feedback from both sides.
And a small wish: when you like the work results, don’t forget to say it. It is a great motivator.
… to solve issues
Issues, misunderstandings, problems are OK. It’s a normal (and inevitable) part of development.
The only man who never makes a mistake is the man who never does anything. (Theodore Roosevelt).
When there’s an issue, face it with your team. The earlier you address it, the less problems it will cause.
Again, remember: your teammates are there to back you up in any difficult case.
The trick is that Developers always try their best to help, offering variants and solutions. But they will never know the product as well as you do. So, their solutions won’t be the most optimal ones.
That brings us to another valuable notion: Do not delegate too much responsibilities to your Developers. Make sure you’re always involved. Otherwise, you’ll get their app, not yours.
… to plan work
Try to drag as many features to the new sprint as Developers can handle — based on previous sprint experience. Don’t let lots of tasks stuck and demotivate your team.
Be ready to say “No” to other Stakeholders who insist on adding as much features as possible. Prioritization is key value here.
… to trust Developers in technical details
This is particularly important with Sprint and Release Planning.
For example: sometimes it may prove not productive to start working on some tasks — when they are not connected with others logically. Writing code for these features will be difficult.
Then, it’s better to follow Developers’ recommendations and fill the sprints with tasks they find related. Such tasks will be implemented consistently, step-by-step, and the resulting code will be optimal and well-structured (which is critical for further scalability).
… to make decisions on the Product
This is the toughest skill.
You cannot be a natural born decision maker. But you can learn. And, if you’re sure about your product idea and have a good team at your back, you can do it.
Optimistic conclusion
One of our QA Engineers, a person with enormous customer experience, once said:
“… In a worst case, a Product Owner may have no serious experience with web apps or software development in general. The critical thing is to be open for communication.
Sooner or later, we’ll get all the right questions to ask. Having the answers, we will get us through the entire work, and finally have a great result”.