Shift from Being a Tactical to a Strategic Product Owner
Tips to Be More Strategic as a Product Owner in Your Daily Grind
The daily grind of the Product Owner is generally hustle at full throttle. The daily considerations that go into aligning teams to produce a successful product, can be mentally draining. I have found that during especially busy times, while managing many complex projects with their unique set of teams and clients involved, it is easy to slip into the checklist mentality, working through the endless list of tasks in front of you as quickly as possible. While efficacy and speed are important when unblocking your developers and hitting milestones, it may not be the most efficient long-term approach. I say this because hitting each task in a tactical manner to just get it done, takes away the strategic and relational quality that makes a Product Owner valuable in the first place. I’ve found that the following approaches help greatly with making that shift.
Mindfulness
When moving a million miles a minute, take a moment to look up and take in your surroundings. Are you still moving your team and product in the direction that was charted? If not, pause to recenter on priorities. Oftentimes, this means looking up from your to-do list or Jira board and restating the goals and vision of the product. Is every thing you are doing derived from these two things? Taking a moment may seem counterintuitive to productivity every second, but it’s one of those realignment necessities that creates long term success for your product.
Having a think-first and speak-second mentality, stemming from the practice of mindfulness, will ensure that your words and actions come from a better place than from a reactive place.
Knowing When to Say Yes, No, and Next Phase
One of the biggest challenges of being a Product Owner is knowing how to balance project deadlines and costs, with client requests, and team allocations. Saying yes to every request that comes from the client will not only put the project timeline in jeopardy but can dilute the project vision. Saying yes without having a deeper discussion with the client to understand needs, talking with the team to understand effort, and truly determining if having that feature now provides the most value in the current context, could be irresponsible. Saying no, without doing the same due diligence can quickly sour a relationship with your client who might not understand the rationale behind the decision. Generally as a Product Owner, the rationale is a reaction to want to protect your team’s time and make sure that the project fits within time and budget constraints. But don’t forget that you are equally representing the client and their vision for the product. It is much better to make sure you truly understand the need first (from all perspectives), then determine if the request can be worked into this phase, is deemed extraneous, or should be slotted for a future phase.
Client Communication
At our company, we have found communication paper trails to be extremely important and valuable. While sending client update emails, status recaps, development review regroups, and the likes can be extremely time consuming, it’s best to set the precedent that you will be transparent with your clients. Your client should never be asking you for an update. This doesn’t mean spamming your client, and you should certainly be as efficient and effective with communication as possible. It means being strategic with how you are packaging the information you need them to see and respond to. Everyone is busy and no one has time to read a novel in email form. Create easy to read bullets and action items for the client to react and respond to if necessary, then always plan to follow up in a status call.
Relationships
It is extremely important to make investments in your relationships both with your clients and with your team. During busy times, I find that I tend to jump right into business without taking a moment to read the email back to myself as the client. Often times it helps to run back through and add some human touches such as “Good Morning, I hope your weekend was great.”
For your internal team, affirmation goes a long way. Our team at Barbershop I/O is blessed with some truly talented and dedicated employees. This often means that we willingly and passionately put our nose to the grindstone. Daily standups and sprint reviews tend to rush past what a team member did do that week and focus on what they didn’t accomplish and why. It is important for the longevity of your team and your company as a whole to recognize good work on the regular. If I start picking up on pre-emptive burnout signals, it’s a good time to take 2 minutes to acknowledge the developer whether it is there and then, surrounded by the team or later, in a Slack DM. This provides the opportunity to better the relationship, increase morale, and unearth any project pain points that you can address.
Know your Pain Points
This generally only comes with experience and having productive post-mortems. By knowing your team’s pain points, you can figure out where to dam the river upstream to mitigate risk. Risk is generally a fancy term for scope creep which is part of the terrain when building new functionality with new technologies. Use project boundaries strategically to know when you are letting stakeholder requests muddy the waters or certain features are taking much longer than expected.
Plan for the Worst Case Scenarios
Before they strike. A lot of pain points can mitigated by planning.
Prioritize
This one goes without saying. If you are a Product Owner and your brain doesn’t see everything through a priority lens, what are you even doing?
Be Proactive
Plan ahead for the times you know will be wall to wall busy. Our team at Barbershop recently began documenting protocols and checklists for everything from new project setup checklists, to app store submission steps and procedures. By developing this documentation, it’s now much easier to get ahead of questions and needs that would otherwise potentially derail the project for a day.
All in all, a Product Owner knows that the devil is in the detail but don’t be so consumed with looking for the devil that you can’t see the forest through trees.
