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 . This will make our life happier. the critical attitude we expect from them 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 a Project Manager! is absolutely not 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 who: Leader 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? becomes the Knowledge Keeper for the Product. What’s vital: knowing and are equally important! Product Vision: what the product is what it’s not The instruments for putting down this Vision are (the plan with the business goals and technologies, used for achieving them) and (the list of Products, sold/developed by a company, often — in different stages of Scrum development/production). Product Roadmap Product Pipeline gathers new features the future Product must have, maintains and prioritizes that knowledge base. Product Backlog: The core competence here is estimating the of these functionalities, and thus prioritize the Backlog, answering the question Business Value “What gives us more business value with less efforts/expenses?” writes documents that explain to Developers: User Stories: 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 ( ), and thus — which functionalities have to be postponed and done later. Sprint Make sure these features are fully functional in the last stable version of the Product (Release). participates in: Coordination of Development Team’s Work: 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 connects Developers and Stakeholders on all possible issues. This is exactly where the famous motto of , , is applied the best. Collaboration: Agile Manifesto “Individuals and interactions over processes and tools” 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! 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. Try to answer questions as soon as you can. … 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: Make sure you’re always involved. Otherwise, you’ll get . Do not delegate too much responsibilities to your Developers. 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. is key value here. Prioritization … 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”. More useful articles you can find in our blog Primary source

Read My Stories

Too Long; Didn't Read

Developers: Build Less. Deliver More. [Learn how]	

Web Development: the Most Precious Advice to a Product Owner

Too Long; Didn't Read

People Mentioned

Django Stars

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

Web Development: the Most Precious Advice to a Product Owner

Too Long; Didn't Read

People Mentioned

Django Stars

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

RELATED STORIES