DON’T HAVE A PRODUCT OWNER? WE’VE GOT YOU!

In Agile development, a Product Owner defines what needs to be built, and explains the capabilities of the project. This post is intended to find solutions for teams who don’t have the bandwidth for a Product Owner, not to suggest that these roles don’t have value. Product ownership is a crucial component of Agile development, but here at Shift, we’re focused on solutions and meeting clients needs wherever they’re at.

Product Owners are the bridge between external stakeholders and the development team, acting as an intermediary between both groups to ensure that the project effectively solves the problem facing the client. Our recommendation for clients is to have somebody in that role while they work with us. It is, however, a large commitment that takes expertise and we understand it’s not realistic for every client to hire/transition a new person just so they can work with us!

Every project at Shift leverages a Delivery Lead and Account Lead to help our client's Product Owners move its product forward. When a client can not dedicate a full time Product Owner to the project, our Delivery Leads set up and assist the Product Owner by keeping things on task.

So, let’s break down the relationship between the Product Owner and Shift's Delivery and Account Leads and demonstrate how we can accomplish those tasks by dividing the workload across our team and yours.

User Stories

One of the primary responsibilities of a Product Owner is to break down user stories for their project. A user story is a small, testable goal written from the perspective of a distinct user. In essence, they help to define what people will actually be using the software for. For example, if you’re looking to add Multi-factor Authentication (MFA) to your product, user stories might look like this:

• As a user, I want to be able to link my account with an authenticator app so that my data is more secure.
• As a salesperson, I want to add MFA so that we can receive a security certificate.
• As an administrator, I want to add MFA so that we reduce our companies exposure to liability from phishing attacks.

User stories help define what each stakeholder is getting out of a new feature or project. As you can see in the above example, each user wants to increase the security of the product but they all have different reasons for doing so. By breaking out their perspectives into stories you and your team now have a checklist of things to accomplish before you consider the feature ‘done’. For example, if MFA is implemented poorly, and your product fails to receive an industry standard security certificate, that’s one less tool your sales team has! User stories help define how people will use your product, and what to look for when measuring progress.

So, how do you put these together without a Product Owner? Here at Shift, we use a collaborative process to sketch out projects with our engineering and delivery leads teams. Basically, our team will meet with you and discuss what you’re looking for and the purpose of the project. After those initial discussions, we can put together stories for your team to review and collaborate on.

Define Product Roadmap

Another crucial responsibility of the Product Owner is putting together a vision for the entirety of the product. Software can be very complex, and having someone to sort through the order of operations is crucial. By leveraging user stories, Product Owners work with developers to decide how the project will be built. At Shift, our Account Leads can step into this role. For example, if you’re looking to add a loyalty program to your e-commerce website an Account Lead would say you need to have:

1. The ability for users to create an account
2. A database to store user activity and accumulate points
3. New pages on your website for users to redeem points
4. Code changes to accept points and apply discounts

Now, imagine building the page to redeem points before adjusting the database. Your customers will see tantalizing deals with no points and no way to get them!

If you don’t have a Product Owner to define the roadmap then we recommend a collaborative effort between our Account team and you. Shift offers a great way to do a deep dive into your product, called MVP Validation. By leveraging user stories and similar documents, we can help define the entirety of the project from the start. By knowing the destination, our team can help define the best way to take the journey.

Measure Progress

So now you know how people will use the product and how we need to build it, all that’s left is knowing how much progress has been made. Here at Shift, we use Agile development, which means we break out our projects into small goals and are constantly iterating to deliver continuous value. So, instead of laying out a plan and never deviating, we are constantly looking for ways to improve the end product.

Imagine you’ve hired contractors to build you a house. Using older methods of project management, you’ll be told how long it will take and how much it will cost upfront. But the bathroom tiles get delayed in shipping, which means the contractors can’t finish your bathroom on time and the whole project gets pushed back and you can’t do anything about it. Conversely, with agile, you’ll get a call about the bathroom tiles potentially causing delays, and are given options to get the project back on schedule. You can choose different tiles that are readily available, the contractors can focus on a different part of the house while waiting for the shipment to arrive, or you’re given a list of things that can be done faster in order to make up for the lost time.

Instead of staying theoretical about how to measure progress, let’s just run through what a typical sprint looks like for our clients while their project is in development:

• Our developers and delivery team put together a sprint, which represents all the work that will be done over the next two weeks. This work aligns to larger epics or milestones you’re working toward.
• Our account and delivery teams will communicate what work will be done with the client.
• Right before a release is ready, we’ll meet with the client and demonstrate all the work that has been completed.
• The delivery team works with developers and the client to put together the scope of work for the next sprint.
  • During these conversations, clients and developers have opportunities to iterate, making changes to the project that everyone agrees with.
• The client is given an update on how much of the project has been completed, and what work remains.

The key to measuring progress is having somebody who is constantly communicating. Typically, this is done by the Product Owner but in the absence of one we’re happy to step in and act as the go between between the developers and your team. Having a Product Owner is a wonderful way to go about developing software, but we recognize that our job is to help all clients succeed no matter how much experience they have with development. Which is why we’ve built out processes to make sure all the responsibilities of the Product Owner are covered even if you don’t have one.

Don’t have a Product Owner and need help getting started? We’ve got you.

This article was written by Harrison Postler, Delivery Lead at Shift.