The Product Development Hike.

You won’t read far in product development, where product road map analogy (or actuality) is brought up. Recently, I saw a tweet (is it still called tweet, or is it an X) from @CGLambdin. I wish I had captured the tweet for posting here, but I recall it was about the metaphor that product road maps are not very apt for product development.

For example, roads are traveled by others. Before there were roads, there were often trails through the woods, existing routes, or, in the case of our analog, existing products. Sometimes, this is true for product development; the new product is an increment of an old one, perhaps the use of a new technology improving the product with additional features or improving the product cost or reliability. From experience, most product development efforts are not a start-from-scratch development. A version of new product development does not operate well under the road map analogy. We will need something different.

I am the son of a Special Forces dad who loved the out-of-doors. As a result, I grew up spending much time out of doors as a latchkey kid, a scout, camping under the stars, hiking, capturing snakes, and many other things one would do in those days. My time as a scout taught me the skill of terrestrial navigation (orienteering), and after seeing that Twitter post, I thought there is a better metaphor for product development than roughing it. To provide some frame of reference, we did not all grow up in the ’70s or were scouts; I give a definition below.

Orienteering is a group of sports that require navigational skills using a map and compass to navigate from point to point in diverse and usually unfamiliar terrain while moving at speed. Participants are given a topographical map, usually a specially prepared orienteering map, which they use to find control points.[1]

How does this apply to product development? In the case of our orienteering, we have an idea of where we want to go, but we may not know how to get there. The terrain will impact the route we choose to take; the shortest distance may not be that direct path through a swamp or over a mountain (that being a metaphor for external challenges and company and team limitations).

The history of orienteering begins in the late 19th century in Sweden, where it originated as military training. The actual term “orienteering” was first used in 1886 at the Swedish Military Academy Karlberg and meant the crossing of unknown land with the aid of a map and a compass.[2]

We may know approximately where we want to go with the product based on market research, but we likely know little beyond that. Sometimes, we use or apply a new technology, further creating uncertainty.

Perhaps we should consider dumping the traditional vocabulary of the product roadmap with the vision of paved roads, signage, and the delusion of smooth progress. It is very seldom like that. I say seldom when I put on my engineer hat; I know better than to say always and never. The missus used to say things like “you always do” or “you never do” I told her I am human, even though I am an engineer, and I am not that repeatable.

Product development is often a muddy mess. I chose that phraseology very carefully. I say muddy because a poor direction or decision can lead us to a quagmire where progress is slow, costly, and maybe even damaging team morale. Great learning opportunities, though, assuming we can maintain engagement and reduce the frustration load. We have no doubt all heard that -fail fast and fail often. Failure is not the issue, but the time (and cost) invested and the time (and cost) to get out of the quagmire are often an issue. Imagine product development as an orienteering race. In orienteering, we seek to avoid muddy and swampy areas, fording rough rivers, a thicket of brambles, and where the terrain is inhospitable.

Similarly, product development orienteering aims to create a successful product by navigating a dynamic landscape of customer needs, constraints, market trends, and emergent and technological changes. Or, even more to the point, a hike through the woods requires the same skills as orienteering.

Here’s how the analogy works:

Starting Point and Destination

In orienteering, you start at a designated point and have a clear destination to reach. In product development, your starting point is the initial idea, and your destination is the fully developed and successful product, whatever that might mean. We may not exactly know the destination, unlike the game of orienteering. Still, the same skills apply to understanding objectives (market and customer) and making appropriate decisions (based on where we are and where we desire to be for the next segment).

Checkpoints

Instead of a linear roadmap, you have a set of checkpoints in the middle of the woods, a spot along a river, or a flag posted in some random place. These checkpoints represent vital milestones, such as technology maturation and application, simulations, VR and AR explorations, prototype builds and validation (and verification), feature integration, testing phases, and user feedback loops. This is not new in concept; checkpoints, milestones, and gate reviews apply to many approaches to product development and even project management and management at large. However, in orienteering or hiking through the woods without a trail, those checkpoints may not be so well defined at any given time. This is especially true for checkpoints beyond the next one.

Map and Compass:

Just as orienteers rely on a map and compass for navigation, product development orienteers use market research, user feedback, emerging technology, and technology trends as their guiding tools. The map represents the evolving understanding of customer needs and the competitive landscape, while the compass is the team’s shared direction and vision. Compass is external, and the direction to go is internal and is built on things such as knowledge of the area (topic) overall, available talent, and the communication competencies of the team and organization at large. As we see these new directions, we discover the need for new routes to achieve those objectives.

Adaptive Navigation

Orienteering requires participants to adapt to changing terrains, weather conditions, and unexpected obstacles. Similarly, in product development orienteering, teams must adapt to shifts in customer preferences, technological advancements, emergent technology, and unforeseen challenges (emergent situations), for example, in technology application. Our adaptive navigation will be part of our technology maturation; as we learn, we have questions, prompting further learning and questions (see feedback loops).

Decision-making

Like choosing the best route between checkpoints in orienteering, product development orienteers make decisions about technology applications, system and feature developments, priorities, and trade-offs as they progress toward the final product. What is more important? What less so? What restrictions are there from the requirements or company politics and policies?

Feedback Loops

Orienteers periodically check their progress and adjust their course based on the time they’re taking and their surroundings. In product development orienteering, continuous feedback loops help teams assess their progress, gather user insights, and make necessary adjustments to the product’s development path. Just as a pilot (or the plane in the case of automation) makes continuous adjustments to the course (for example, windage) to ensure the aircraft lands in the correct place, so too is orienteering and product development. This does not just happen during milestone events or from objective to objective. Effective navigation requires selecting the appropriate route and monitoring progress toward the objective (what needs to be adjusted to make the objective). Based on the circumstances, do we need to alter the route entirely? Is it a minor course adjustment?

Exploration

Orienteering often involves exploring different paths to find the optimal route. Similarly, in product development orienteering, teams explore different approaches, technologies, and solutions to discover the best way to fulfill customer needs and stand out in the market. This exploration is often facilitated by team interaction, reviewing the map, suggesting potential routes to our objectives based upon the reading of the map, which path poses the least risk, allows us to move fast, extend learning into specific areas or other parameters we value.

Team Collaboration

Orienteering can be a solo or team activity. In product development orienteering, collaboration within the team is crucial, just like orienteering teams communicate to solve challenges together. Modern technology and the associated difficulties often require a range of domain knowledge and experience.

Dynamic Environment

Orienteering races can take place in diverse and changing environments. In one event, rain, heat, and terrain can challenge us. Similarly, the product development landscape constantly changes due to market dynamics, stability and knowledge of emerging technology, customer behavior shifts, and technological breakthroughs.

Celebrating Milestones

Just as reaching a checkpoint in orienteering brings a sense of accomplishment, achieving product development milestones provides the team with motivation and a chance to reflect on their progress. In these interstitial spaces, the team can rest up and ruminate on the best approach to the next segment, given what is known and what can be read on the map. The plan to make the next piece is created knowing that the conditions encountered may require altering our path during the hike.

Conclusion

Suggesting product development is more like a rough hike in the woods may be more appropriate. However, the same skills from orienteering are applicable. There is value in checkpoints or waypoints, so perhaps we are extending the analogy to the point of breakage. By embracing the orienteering metaphor, product development becomes an agile, adaptive, and dynamic process where teams navigate toward success by responding to the evolving landscape and making strategic decisions at each checkpoint. There is often considerable learning with new technology or new constituent parts of the system. It may not be new, but it can be unique to us and the project, which is the same thing as new things since we have no experience with it.

Change product roadmap to product orienteering.

What do you think?

[1] https://en.wikipedia.org/wiki/Orienteering last accessed 8/30/2023

[2]https://en.wikipedia.org/wiki/History_of_orienteering#:~:text=The%20history%20of%20orienteering%20begins,a%20map%20and%20a%20compass. Last accessed 8/31/2023