Product Management & Land Navigation are Pretty Much the Same Thing
A recent discussion on LinkedIn got me thinking about how I would describe the software development process. Most diagrams show it as some kind of linear path, but as described in a recent post by by Emily Oliver “Roadmaps should be like Decision Trees”.
She further added: “To be “agile”, both lowercase and uppercase, the roadmap isn’t linear. There’s too many players on the field to predict how the whole game will go. Customers, stakeholders, CEOs, risk, industry, politics all can bring change to the focus.”
I agree with Emily’s assessment and how she describes the approach. I also appreciate the diagram from Scrum.org that describes the Scrum framework for Agile software delivery; however, if I were to describe how managing a project like this feels, I would probably describe it a bit differently.
In this case in this case, what I beleive is missing is simply a different perspective. Just like in software engineering, where you have concepts such as the 4+1 Architectural model that provides different views, perhaps there is another view of the SDLC process that can better prepare people for what actually happens, or how it feels, when developing a product.
What immediately came to mind, and something that I have thought about before, is how software product development projects felt a lot like land navigation training back when I was in the military (USAF)…
- You have a starting point, a goal, a timeline, and limited resources (food and water).
- You start by shooting an azimuth to a fixed point in the direction you need to go, then start heading that way while keeping pace.
- Ultimately you will hit obstacles that need to be overcome, some that send you back and some that take you in wildly different directions.
- Each time you face an obstacle, you need to make a decision always considering your remaining time and resources, as well as fatigue that may be setting in.
- You do all of this while maintaining awareness of your objective — losing sight can cost you significantly.
- Sometimes you might even find that the objective is no longer viable and so you need to find another one.
Throughout the process you need to stay agile, maintain an understanding of team health, delegate responsibilities, communicate effectively, watch how you perform against your objective, and negotiate decisions and outcomes.
While I am not sure how this would be drawn, doesn’t that sound similar to managing a software project? Perhaps an illustration does not need to be created, and perhaps saying this only serves as a way to commiserate with other project and product managers, but maybe if you keep this in mind it might help keep things in perspective. It might even be a good way to help set expectations for your team as they take on a new project. Either way, it was something that I thought might be interesting to share.
What do you think? Do you see the parallels? Would you describe it any other way? How do you help your teams and product owners prepare?
If you liked this article, as well as topics related to AI and UX, please follow me (James McGreggor) on LinkedIn and here on Medium.
For help architecting modern digital solutions please visit our company www.blueforgedigital.com.
Thanks for reading!
