In a few weeks, I’m taking a ninety-mile hike around Mt. Rainier. The long-term strategy is to finish the loop in eight days, have fun, take some photos, and not get injured. But I need shorter term strategies as well. The trail gains (and loses) about 25,000 feet of elevation (about 7.62 km - approximately the height of Mount Everest) in the full loop. I have permits for specific camp sites along the way, so I need to plan each day carefully around taking rest breaks, finding water, climbs, descents, eating enough food, and getting to camp sites (ideally) before the sun sets. And then, despite careful planning and preparation, sometimes things happen that are out of my control. A trail can wash out. Animals can block the trail. I could get hurt. Some equipment could get damaged or lost. All of that is survivable – what is important is that I have a strong plan – but that I’m adaptable.
Not surprisingly, the product development world is similar. We need long-term plans. We need to break those plans into shorter plans that help us go in the right direction - and we need to be adaptable. And we need to find balance between all those forces.
Agile, MVP, and the Church of Ries
“Agile” may be one of the most misunderstood concepts in software. A lot of folks tell me that they “don’t like Agile” - but when I ask them why, they describe things that aren’t agile at all (yet again, I link to We Tried Baseball). However, as bad as the understanding of Agile can be, there may be an even more misunderstood word - MVP - aka the Minimum Viable Product.
One of the most impactful books I’ve ever read (and re-read, and re-read) is The Lean Startup, by Eric Ries. In this book, Ries claims that you don’t get value from your engineering effort until it’s in the hands of customers and emphasizes getting a functional product into the market as quickly as possible. This, of course, is at odds with more traditional methods that aim for a 'perfect' product right out of the gate.
I have worked on products where our leadership or product management insisted that we needed more features in order to have an MVP. In every case, we already had an MVP. I often hear people talk about “needing” to add more features before getting customer feedback, or the need to tweak an existing feature, or optimize something that in no way needs optimizing right now.
The goal of an MVP is learning. There’s a story Ries tells where he put a link to a new feature on a web page, and then showed a “coming soon” page when the users clicked the link. He did this to learn how many customers may be interested in the feature before he coded any of it. In later versions of this story, he states that he should have not created the “coming soon” page at all, as he could have gathered the same information from a 404 error as he could get from page hits - with less engineering effort.
This is the benefit of fast feedback loops. One of the significant advantages of releasing an MVP is the ability to collect customer feedback quickly. This feedback leads to quick iterations and further learning. This is the short-term plan. Get a product into customers hands, learn how they use it, and adapt.
Balancing Adapt and Pivot
I am not sure if it is possible to build a product entirely on short term plans and fast feedback loops (someone will tell me if I’m wrong - the internet is good at that). In most cases, we need to balance fast feedback with longer term direction and adaptability. Twitter (ummm X??) started as a place to find and subscribe to podcasts - they adapted. Instagram was originally more like a Foursquare clone - they adapted as well. In both cases, I expect these companies had longer term visions around podcasts and check-ins respectively, but they saw a better opportunity and pivoted.
The Bigger Picture and the Famous Cone
I’ll repeat this again, because it’s important, and a lot of teams forget. You need a plan and a vision, but you need to execute in small chunks of customer value that let you learn what your customers find valuable. Your plan does not need to be perfect (in fact, a long-term perfect plan is impossible, so don’t bother). The concept of a Cone of Uncertainty means that your plans are less accurate and more ambiguous the farther they are in the future.
Back to the Trail
Part of my plan when hiking a long trail is to reflect and adapt. If I know I need to hike 15 miles with 5000 feet of elevation gain in a day, all I can (literally) do is plan the next steps. I may plan to hike to the first water source and take a quick break. From there, I can assess how I feel and come up with the next set of next steps. Sometimes, the miles fly by. Sometimes they’re more difficult than I planned. Sometimes, I just find a nice place where I want to take a longer break and take in the scenery.
Again, the parallel with product delivery is prominent. I may know that a year from now that I want a hyper-mesh network with neural nets and automatic model training, and that today, all I have is a pile of data, all I can now do is figure out what my best options are for next steps - and then get whatever that is in front of users so I can see if there’s value or not.
Define the current state. Describe the desired state. Focus on next steps.
Balance
Agile Estimating and Planning, by Mike Cohn is a great resource for understanding how to balance the long-term vision with short term delivery. The book discusses how traditional project planning, which is often rigid and linear, doesn't work well for modern software development. Instead, Cohn proposes an agile approach that is iterative and adaptive but still guided by an overarching vision and goals. Cohn talks about Adaptive Planning which encourages teams to accept changes as a natural part of the development process, and that by adopting a more flexible approach, teams can adapt to new information or unexpected challenges without losing sight of their long-term objectives.
Balancing between the long-term vision (desired state) and short-term delivery and learning is critical. If all the emphasis is on the future, people will lose interest, because nothing is happening now. If the emphasis is purely on the small steps and delivery needed for learning, then your customers (and your team!) lose track of the purpose of what you’re building and lose interest.
Communicate the vision.
Deliver small steps towards that vision focused on learning.
Re-evaluate the vision.
Goto 1
Build and Deliver
Let’s say I want to build a smart watering system. In Inspired, Marty Cagan talks a lot about building products that solve customer problems, iterating, and focusing on outcomes. It’s a great book for Product Management - but perhaps even more valuable for those working in teams that do not have Product Management.
For my Smart Watering System, I’m solving the problem of over watering or under watering plants. My solution to the problem (and product vision) is an IOT device that monitors soil moisture and delivers water when needed. My initial iteration may just be a device that measures moisture and beeps when the soil is too dry. If that provides value, my next iteration may communicate over Wi-Fi and send a message to someone telling them to water the plant.
Eventually - and perhaps many iterations later, I may end up delivering on my initial vision. Or - because I’m prioritizing learning in fast feedback loops, I may find reasons that my initial vision just won’t work. Maybe similar devices already exist. Maybe the device is too complex. Maybe it’s too expensive to build. Or I may discover that over and under watering isn’t as big of a problem as I thought it was.
I re-evaluate the vision based on learning, and I need to be open to the fact that my vision may need to change. It’s time to pivot the vision.
I may find that monitoring soil nutrients is more important than moisture. Or maybe it’s lighting and I pivot the product to focus on making sure plants have enough of the right kind of light to grow. Or maybe I discover that a Total Plant Health System that covers all of this is where I can find market fit. Or maybe folks love the reminders about water, but want more reminders, and an IOT driven reminder device and app for home maintenance is the right product to build.
Communicate the vision. Focus on next steps. Pivot and re-communicate if necessary.
Value to the Customer
Ultimately, what I’ve (attempted to) describe above is that customers deserve both a compelling long term vision, and frequent updates that provide value for them (and learning for the product team). Tell them where you’re going, give them small steps towards that goal, and let them know if/when the vision changes. Of course, that same communication internally to the team is necessary as well. Know where you’re going, move in that direction, and adjust and adapt along the way.
-A