Product ownership is a key piece of the puzzle that is digital product development. At Spire Digital, business analysts and product owners perform this function, working with clients to decide what to build and when to build it, and in turn, create actionable work for Designers, Developers, and QA Testers. Throughout my tenure in this world, I’ve learned a thing or two about successful product ownership that I figured I’d share here.
Before we get started, here is a quick glossary of terms:
Acceptance Criteria (AC): Tasks a User needs to complete in order to consider a feature done. These are binary tasks, meaning either a user can or can not.
Ticket: In theory, this is everything a Developer, Designer, and QA Tester needs to know to build a meaningful feature.
Roadmap: Project schedule that determines when features are being designed, when feedback is due from the client, and when designs are built by devs and tested by QA.
Schema: Visual representation of a database.
Now, on to the knowledge…
This isn’t a joke. You literally need to know everything about your tools, requirements, APIs — anything that you might be working with. The second that you second guess yourself is the second that your feature or acceptance criteria no longer matters to your devs, clients, designers, etc. It is also the second that your roadmap risks running off course.
Take the time to know exactly what your tools will do/will not do and exactly what functionality you are building, so you can answer any question at the drop of a hat and provide a “why”. Also, so you can plan and estimate the custom development required when the tool doesn’t exist or falls short. Be the expert and people will align with your vision. A Product Owner who designed the schema and knows the API backwards and forwards is a very powerful weapon.
This is what you need to do to avoid the “Oh crap, it works!” moment. Let me explain: You are building share-to-social for a native app. You assume your developer will craft this feature to share natively, but you don’t specify that you are planning to share natively in your ticket. Well, you know what they say about assumptions. Without your direction, your developer builds it to share to mobile web. Now you have a feature that not only works, but hits all of your AC and you’re still disappointed, hence “Oh crap, it works!”. No detail is too small to include in your ticket. Your team would rather have too much information than not enough, and you’d rather have the feature as you envisioned it.
Write For Your Audience
Every person is different. That means that every Developer/Designer/Tester that you work with is going to be different. You can’t write tickets based on what works best for you. You need to write tickets based on what works best for your team. A good Business Analyst sits down with their team at the beginning of the project to find out what ticket styles and ways of working they prefer. If they have been working with their team long enough, chances are they already know and will adapt their tickets regardless if they meet at the beginning of the project.
Writing to your audience will save you a lot of time (i.e. hours of wasted development) and heartache (frustration from a lack of shared understanding) in the long run. In the end, every ticket needs to define done and, for us, contain binary acceptance criteria. HOW you get there in the most simple, most clear way will, and should, vary individually, based on the learning and comprehension styles of your teammates.
Listen to your team
I know I said earlier that you need to know everything, so I’m about to contradict myself here. Your team may know something you don’t know about actually designing and building a feature faster, more elegantly, more scalable, etc. Their feedback about your requirements is important. You don’t want to design a feature that looks beautiful if it is going to take a million years for your team to develop or it isn’t compatible with the database. If there is an easier way to do something, your team will probably know. Empower them to offer alternatives. Take the information your team provides and use it to ship a better product faster.
People don’t like change but it is after-all at the core of the Agile methodology. The quicker you learn to embrace it, the better. You were planning to build a feature this week, but the end points don’t exist? So what, move it back. I bet you have another feature in your pocket that can be developed, while buying yourself some time. Your roadmap is an ever-changing document, don’t paint yourself in the corner by trying to stick to it. Your client wants to add features? So what, do it. Just make sure they know what they are sacrificing to do so.
Adapting to new information as it comes at you is at the heart of being a PO or a BA. You will learn new things that will influence your product for the better at all points of a project. Use that information to change your product for the better. Don’t forget that no product vision survives contact with the customer….change is coming.