If a Product Manager (PM) isn't working a minimum of 50 hours per week, they're not putting in enough effort. So say a few popular leaders of the Product community.
Though I once fell for this, I disagree. Earlier in my career, I considered a 50-hour workweek anything but long. Putting in more hours seemed to be a means to an end. "If we can just get this release out the door, things will slow down." How many times have you said that to yourself?
As a PM at a fast-growing North American freight brokerage, I've got skin in the game. The logistics industry, typically cyclical, is experiencing unprecedented volatility thanks to a variety of market forces. In this environment, technology innovation and adoption can't seem to happen fast enough. As more logistics organizations adapt to changing market dynamics, product teams play an increasingly crucial role in meeting customer demands.
This post explores ten steps PMs can take to avoid the common pitfalls of working in high-growth environments. Read on to learn how to excel at providing value within your organization while bringing products and solutions to life.
Whispering Talent - Part 1: How Freight Brokers Can Find Hidden Potential
Whispering Talent - Part 2: How Freight Brokers Can Develop Hidden Potential
Organizations go to great lengths to stack their teams with A-players. In a previous role, I was part of a product team that checked a lot of boxes – we were well integrated with Engineering and practiced Agile Scrum to a T. But beyond the surface, we were a disaster.
It was every man for himself. Feature releases were a last-minute scramble and always later than promised. Marketing campaigns fell flat. The executives wanted new feature releases that didn't align with customer needs. The Wild West is a well-suited metaphor as it did not translate to the modern world and belonged in the past.
Like anyone, PMs can't burn the candle from both ends for long, and success eventually runs dry for companies who don't use customer feedback to influence their roadmap. Nor does success last for organizations operating without data driving their decisions. At the heart of any tech company's success is its Product team, and that team can't perform its best if they're running around with guns blazing. They need to be methodical. They need to operationalize. Above all, they need to be strategic.
PMs are like cattle drivers. They take the reins and tame an organization's Wild West ways.Consider slowing down in favor of a phased research and development-based process, which will speed delivery, support effective launch campaigns, and yield better returns on investment (ROI). It takes diligence and practice, but as an old western saying goes, "There's a whole lot more to ridin' a horse than sitting in the saddle and lettin' your feet hang down."
Executive teams are often full of subject matter experts and are tremendously valuable to guiding the Product organization's focus. But they should never be the only source of truth. PMs can provide value to the organization by:
Who said you couldn't daydream at work? Assemble a brainstorm and think with your head in the clouds. Gather perspectives from UX, engineering, support, sales, marketing, and any other relevant teams. Imagine how to solve for your opportunity in a world without deadline, budget, and staffing constraints. Then, bring yourself back down to earth. Ask your engineering team for help determining what is feasible and reasonable to deliver. They can help you narrow your idea scope and begin defining requirements. Add the additional details from this phase to your opportunity assessment.
Don't leave your product's success to luck. You know which personas your solution needs to target, so share your ideas with those audiences and repeatedly iterate until they say you've got it right.
Next, help your executive team find a home for your product on the roadmap. Whether it requires next-in-line attention or needs to wait until another opportunity is complete, confidently express your recommendation to the executive team. After all, you're the one team member that has a direct line into every department. No one should have a more well-rounded perspective than you.
With a more solid vision for your solution, mock it up in wireframes or a prototype – anything that makes it more tangible.
If you had a brilliant idea before testing, but it doesn't resonate with users, leave it out of scope. Squashing a bright idea can hurt, but don't add effort and scope to a solution that users won't use or purchase.
Once you've solidified your solution's functionality, work with your engineering team to translate feedback into executable backlog items. Not only will this simplify backlog grooming sessions, but it will also give engineering an idea of the workload on which they'll be asked to deliver.
Lastly, make sure to keep your refined business requirements in a place where they can be shared with your executives. Subject matter experts should have access to weigh in on anything they think is missing or should be sought with caution.
As each portion of your solution reaches a customer-satisfactory definition and the requirements are translated into workable engineering items, start feeding them into the backlog. Don't wait for every piece of the solution to be defined before the work begins. Engineering will run into previously undiscovered hurdles. You will be faced with a compromise on functionality and design. Embrace it. There's always more than one way to skin a cat.
As each piece comes together to form working portions of your feature or product, send it back to user testing to make sure you're still on the right track.
Why is the 'launch' phase grouped with the 'build' phase? Because you should begin preparing your launch plan long before completion. While your product is in development, take the opportunity to pull your team together. Start outlining all of the training, help documentation, and marketing collateral that will best match your solution's release. Assign owners, contributors, and reviewers for each item. Make sure everyone's content is written in an appealing way for the target personas. PMs should be content owners or at least a collaborator. By this point in the process, nobody should know your end-user and present this information to them better than you do.
Once your team has decided that your solution has reached stable and consistent ground, it's in 'maintenance' mode. This doesn't mean you walk away from it. Bugs will pop up, and so will minor enhancement requests. Continue to dovetail these with other sprint items as needed.
However, because you have reached the initial solution's success criteria, any new significant iterations should go back through the process. Bugs and minor enhancements should never go through the process. You'd likely spend more time investigating them than it would cost to complete the engineering effort. The same goes for solutions where you find that potential ROI far surpasses the cost to build. Once you realize this, skip some of the more arduous in-depth analysis and definition work, and head straight for mockups, quick tests, and building.
Apply the pieces that are missing for your organization. A process should work for you, but you shouldn't work for it. Be confident experimenting and evolving. After a couple of rounds, you'll begin to see that the Wild West is in the dust and what was once every man for himself is now a cohesive unit working systematically toward the same goals.
If you're interested in working with our team or connecting with us to discuss how to apply best practices to your organization, reach out to us today, and we can get you in touch with our product experts.