I often get asked what it is that I do for a living. Ordinarily, when I answer that I’m a Product Manager, most people give me a blank look – and I realise that I need to explain the role of a Product Manager – who we are, and what we do.
Product Management is an essential part of the software development process. While we might not be the captains of the ship, we have a hand in the steering of it. If you like puzzles and solving problems, then it’s possible that Product Management is a role you may enjoy.
Most of the time, I find myself trying to figure out how to get the puzzle pieces to fit together to create a viable release. Some days I feel like I am trying to squeeze that last item into the back of the car before a road trip.
We are the touch-point between the Commercial, Support and Development teams in our business. We are listening out for industry news, looking forward to where we can take our product next. We are listening to our customers, looking to see what you need and what we might be able to do to make your working day easier. Maybe there is a pain point in the software that needs some love. We’re constantly looking to find out if there something new in the marketplace that our users would like to see in our software, or if we can introduce something new to the market.
My favourite part of this job is solving a pain point for our Practice users and making a workflow easier for them to use. We take that pain point and see what is missing, or what we have that can be enhanced to improve outcomes.
Product and Feature Requests
Reviewing enhancement requests that our users send through is another significant part of my role. On average, I receive 3-5 requests daily for feature enhancements, or for totally new features. Of these requests, some are straightforward, and it is clear as to what the user wants to achieve. Other times, I know our software does what the user is asking for, so I assist by explaining the process. Depending on the request, I might organise to speak with a Practice directly to better understand the issue.
Each enhancement request is reviewed by a wider team to see if the work is viable, and to determine how beneficial it would be to our user-base. At this point, the ticket is either accepted, and the feature is added to an upcoming release, or it may be rejected. It might also be bundled with a number of other similar requests to help enhance a feature overall.
From here, I organise meetings with the Development team and break the requested feature down into smaller, more bite-sized tasks. The Development team look at it and figure out what needs to be done, and how long it will take to do it.
Then I start to arrange the puzzle pieces and work out which features are going to be included in an upcoming release. A release is generally made up of a number of features – some requested by our users, others driven by government. They can be time-critical, where we are required to build a feature to a deadline. They also can be driven by environmental factors – like the current COVID-19 pandemic.
The challenge, then, is to work out the priorities of those items within the release. These are aligned with the following areas of our business:
I then do some more planning, and then just for something different, I plan some more.
Our development team then take the reins, and they work off the priorities set by the Product Manager. The work is organised into two-week blocks that we call sprints. We have a daily stand up meeting to touch base, update the team and look at any immediate priorities that have come up in the interim. There can be any number of sprints in a release. Historically, we have had larger releases, but we are currently aiming to re-focus on shorter releases.
The Testing Cycle
Once we reach the end of the development period, we send a build out to a group of practices who install it in their Practice and put it through its paces in a live environment. They will let us know if any issues arise from the build. We call this the Beta cycle.
This cycle can be short or quite extensive, depending on how many issues are identified in the beta build of the release. As we fix each bug in a build, we push a new beta build out to Practices until we’re confident that the release is functioning without issue.
The last stage before public release is to produce what is known as a Release Candidate (or RC for short). The RC process is generally quicker, as by this stage we hope to have all major kinks ironed out. This build is then a candidate for release.
While this is all happening, we are working with other teams within the business to make sure that our internal team is trained in any new features, our marketing for the release is on track, our sales and support teams are ready and our training is organised and documentation prepared. The role of a Product Manager involves a lot of puzzle pieces.
I keep the team updated on the progress of our Beta/RC builds so that everyone is aware of when a release is scheduled. Even with the best laid plans, I still need to juggle what makes it into the finished products. I need to balance time and resources to determine what can reasonably be included. Sometimes, a feature might be more complex to implement than initially thought; other times we’ll have priorities change at very short notice – meaning we may have to bump a feature into our next build.
While this is all happening, I’m constantly looking forward to the next 3-6 months to see what is coming up and what needs to be planned for future releases.
So, what’s the takeaways from all of this?
To fill the role of a Product Manager, you need to be able to balance many different requirements, and be acutely aware of your users to ensure you’re providing them with a product that they are happy to use. The role of a Product Manager is a challenge, but if you’re cut out for it, a challenge well worth the effort.
Authored by:
Shar Trewben
Product Manager at Best Practice Software
