Product Owners: A Guide to How BRS Keeps Their Clients Involved Every Step of the Way
Here at BRS, we’re fond of saying that our clients are product owners, and we build processes to drive this home. Pull up a seat, as this post is aimed at shedding light on exactly what that means, as well as illuminate how it’s reflected, practically speaking, in our applied agile process (and the methodologies we use to stay organized). In case you missed it, check out our previous discussion about project management at BRS, which helps offer context for this deeper dive into roles and process. Read on for a closer look at the role our clients take within the larger development process, and why we believe their close involvement is so crucial to building a great product.
Product [Owner] is King/Queen
Let's start with defining the role of product owner, so everybody is on the same page. While notions of ‘product ownership’ have evolved in different capacities across different industries over the years, the product owner we’re talking about is one of the core roles in any Scrum team. A Scrum team also consists of developers (us!) and a scrum master (me, as project manager!). The product owner maintains the vision of a product, is responsible for conveying that vision to the rest of the team, prioritizes and defines all work in the backlog, and serves as the final arbiter of when a feature is ‘done.’ The product owner should also have the best understanding of the product’s users, competitors, and the larger market within which it will be built. The quick takeaway here? Our clients are subject matter experts that maintain the vision of what we’re building, and their involvement helps keep our team focused not just on building a great product, but on building a product as close to its original ideation as possible.
Tips for Successful Collaboration
We fully recognize that clients may not have any formal experience in this role, so we’re here to support you and guide you through the process. As such, we’ll work together to define and cement down our meetings and responsibilities at the outset of project. In order to frame your involvement, here are a few general expectations we have for our product owners:
Be engaged! Being present during meetings, timely with feedback, and proactive with upcoming work makes all the difference in the world, and can ultimately have an enormous impact on our team’s efficacy. Collaboration and iteration are fundamental to developing software, and you’re a core team member, so being engaged is crucial. Without said engagement, our team often has to make assumptions, and we all know the dark path that leads down.
Ask questions! Don’t be afraid to chime in if you don’t understand something, need specific feedback on a given feature or decision, or simply want another opinion. The better our communication, the better the product will ultimately become.
Be flexible! Software development is so fraught with unknowns that a whole new way of managing work had to be introduced (enter: Agile). It’s inevitable that feature requirements will change, product phases will expand or contract, and estimates will be inaccurate (or... creepily accurate). While we build process to accommodate for much of this uncertainty, keeping an open and flexible mindset as the work progresses is key.
Where the Rubber Meets the Road
In order to paint a clearer picture of product ownership and its corresponding responsibilities, let's talk through how we incorporate our product owners into the different project phases at BRS.
Planning
The first step in any project is always the planning phase; product owners are the visionaries and creative force behind the impending project, so we rely on them heavily during the planning process. Depending on how robust and well-documented the product vision is at the get-go, we may recommend a significantly more involved application planning project (scoped separately) as a precursor to the development work. Ultimately though, planning means a deep-dive into the product vision: lots of brainstorming, note-taking, and distillation of ideas and information.
One notable function of the planning phase is creating wireframes (read: design documents that capture basic user workflows and interface functionality). This is a hyper-collaborative process, where we begin with hand drawn sketches that eventually evolve into more precise and actionable design deliverables, according to feedback from product owners. While BRS may throw out some ideas to get the creative juices flowing, the actual conversation and final design is very much an iterative process tackled via a series of workshops.
Development
With planning wrapped, we move into the development phase. We lean heavily on Scrum and Kanban for this phase, though we’re open to other methodologies should clients request them. Primarily, we utilize Scrum to inform team roles and meetings/sprints, and we use Kanban to help the work itself stay organized, though there’s definitely some overlap in this Venn diagram. Here’s a more granular breakdown:
Applied Scrum at BRS
As a team, the first order of business is to define our sprint length. Sprints are arbitrary increments of work during which the dev team works to complete defined goals, demo the results to the product owner, and then define the work for the next sprint. We love two-week sprints at BRS as it affords us the right amount of time to build, iterate, and plan. In order to stay organized during these sprints, there are defined ‘sprint ceremonies’ (think: traditional meetings), most of which the product owner takes part in. Of particular relevance are standups, which are daily check-ins that provide all team members an opportunity to discuss current work, imminent work, and any roadblocks in their path. Standups promote communication and transparency. Another key meeting every sprint is a combo deal: demo and sprint review, during which our developers walk everyone through the features they’ve built, and solicit questions, changes, and seek final approval from the product owner. The core goal here is to make sure that our clients have a finger on the pulse of the development process, are seeing new features as they emerge, and are making sure that these features align with their goals for the product.
Applied Kanban at BRS
We’ve talked a lot about the people involved in our projects so far, but it’s also important to discuss how we document, prioritize, and track the progress of the actual product that we’re building, and how product owners access said work. The answer is sticky notes! Or rather, the digital representation thereof. In Kanban, cards (representing work) are moved from left to right, lane to lane, as they are worked on. This makes it easy to visualize where a given feature is in the development pipeline, and limit work in progress so we’re not biting off more than we can chew.
Short and Sweet
And there you have it! A quick breakdown of product ownership here at BRS, and how the role fits into our larger applications of Agile, Scrum, and Kanban. It does bear noting that while this is a high-level summation, every project is different, and thus client involvement can change depending on many factors - both internal and external. The key takeaway here is how important client engagement is to building a successful product, and how we try to structure phases, meetings, and general collaboration to promote this engagement. If you have any questions or comments, we’d love to hear them! Shoot us an email at hello@bigroomstudios.com.
