In the first chapter of this series, we’ve touched on the idea that the Details are making it harder to Deviate when needed. In the previous chapter we’ve seen one of the principles of The Iterative Roadmap, to avoid and postpone the Details as much as possible.
In this chapter, we’ll deep dive into the Details themselves. We’ll see why they are another source for disappointments, one out of commitment to content and design; And we’ll see why they are also a source for potential Blockages and inefficiencies. Through both, we’ll learn how to make our Roadmaps even more beneficial.
The Specifics
Let’s presume we have a Roadmap for an entire new product, one perfectly divided to 10 Deliverables. Our research has concluded that PayPal would be best for the product’s future payment requirements. We’ve even contacted PayPal and got a really good offer. The integration with PayPal would be done on the 5th Deliverable.
We’ll start working on one Deliverable after the other, one per Sprint. While doing so, we’ll be coding with a future PayPal integration in mind. Because the Roadmap clearly states it will happen.
4 Deliverables and 4 months later, we’ve been contacted by Stripe and given a 20% discount over PayPal’s offer. It is valued at hundreds of thousands of dollars. As there is no way to say no to that, it was accepted by the CEO himself who is 5 ranks above us.
It has happened beyond our reach and control. But for us, it has created a Deviation, one that entails Changes to past work. It has happened because 4 months is a lot of time for things to happen. Such as a Feedback given, because we’ve left an opening to get one.
So even though we have a Roadmap, which is supposed to prevent such occurrences, we may have ended up with unawarely coding Blockages and potentially changing the entire product design, UX and technical implementation, past and future.
How come? Because in its entirety, the Roadmap and ourselves were locked into one very specific Detail. Tightly coupling our design and code to PayPal. Thus, creating the potential to Change everything.
Timing is Everything
As time passes, we gather more and more information. Information which helps be do more informed decisions, better decisions. So maybe counter-intuitively, the more we would have postponed the PayPal decision, the more beneficial it would have been. Seems like deciding too soon is non-beneficial.
As such, a Roadmap should allow us not to decide. Not until we are informed enough, or until external events eventually rise, such as the imaginary Stripe discount. A Roadmap with less Details. The lesser the Details, the lesser the odds of Changing past work. The lesser potential inefficiencies, the more beneficial Roadmap.
A technique to do so would be to drop the name PayPal from our design, Roadmap and Deliverables. Instead, let’s name it “Integration with a 3rd Party Payment Vendor – To Be Decided”. This would force the code and our design to be agnostic to who that vendor is.
As a result, it would give us the time needed to finalize our decisions. More so, it would prevent us from coding a Blockage. The one we unexpectedly needed to remove 4 months into the Roadmap. The same Blockage that won’t need to be removed 5 years into the future, when we’d wish to move away from PayPal.
Details affect product managers and designers as well. It was the Details that have caused RapidAPI’s designer to continuously update the product design. We had just come full circle with the problem we started this series with.
I’m not a product designer, so my suggestion would be to keep some of the design as a wireframe for a while. To not dive straight into the entire UI/UX/CSS and such. Do so upon demand, as R&D makes progress.
Emptying Promises
Roadmaps create expectations to be executed on time. More so, expectations are set to what we promise to do and promise how to do.
“What do you mean no PayPal? We’ve already promised this to our customers! It was in the Roadmap!” is the sound of a disappointed Customer Success team member. It might be followed by some very disappointed customers.
“What do you mean by AWS ECS instead of Kubernetes? We were really looking forward to it!” is the sound of some very disappointed engineers.
Disappointments are the outcomes of Roadmaps with too many Details, and with promises given too soon. If Details set expectations, we better set better expectations.
“We expect an integration will be done with a 3rd Party Payment Vendor” is a better expectation to convey to everyone. It would be okay to add “We’re considering PayPal, Stripe and there might be others when the time comes”. Less firm expectations would create fewer future disappointments.
It’s hard to notice, but there’s even less to set expectations to. We may have too soon presumed that payments need to be automated. Or needed too soon, maybe not in 4 months but in 1 year. A less firm expectation would be “we are going to resolve the need for payments”. The need itself is also the minimal Detail required for a Deliverable or a design.
Details can not remain minimal forever. But we can choose when to elaborate, and we already know when to – when we are most informed. And when we can no longer postpone it. The optimal timing to elaborate the Details would exactly be when the necessity to fulfill the need rises. And as close to execution as possible.
Notice when we set expectations, we set them not for trying. We wouldn’t be “trying to resolve payments”. We do not try, we resolve. We manage and set expectations and get them done.
Unfortunately, even this expectation can lead to a great disappointment. It may end up not needed at all, because we got it wrong. So, an ever-lesser expectation could be “we are going to explore the need, if and when it rises”. And it’s somewhat predictable that we would one day.
These kinds of minimal expectations and minimalized Details are the building blocks of Long Term Roadmaps, which we’ll get too soon. Our day-to-day Iterative Roadmaps would push elaborating the Details, exactly to the point of execution. To avoid disappointments as much as we can.
Attachment to Details
More than just making Changes to code and design, Details make it harder to Change other people’s minds. That is their psychological effects. And we’d need to overcome those Deviations happen.
At Silo (2019), we had a meeting with the CEO/Founder, a mechanical engineer, and the newly recruited Business Developer, a Computer Science graduate. Both very intelligent and smart people, none had any experience in B2C online sales.
Two minutes into the meeting I realized it was not about “we will need a sales pipeline in a year from now”, as it was more than a year before the product was ready for manufacturing. The meeting was about “this is the future sales pipeline”. The rest of us were kindly asked for our opinion, but it was already too late for that.
As I have scraped hundreds of eCommerce and sales pipelines, and had some experience in product management, it was easy for me to point out the faults of the suggested one.
A customer would have to walk through 7 different screens to make a sale. On one of those he’d have to click about 12 different buttons and dropdowns to customize his order. Which was mandatory. And the final blow was that a customer must register and login before they pay.
Honestly, it looked exactly like an engineer would do it. Another good reason to have the perspective of a product manager.
“Yeah… you might be correct… but we have thought this through”. By reviewing it, and unfortunately tearing it all apart, what I did was to sever an emotional bond created between them and their hard work. Tried and failed, because the bond was already hardened. The Details were the ones that hardened it. Which led them to invest 10 hours into it, a year too soon.
Mentally speaking, what we do with new information is to compare it to our existing mental models. The ones in our minds and brains. The more the two fit and overlap one another, the easier it is for us to accept the new information.
Unfortunately, the more Details the existing mental model has, it would less overlap with the new information. The harder it would be to accept and process new information.
Some people sometimes react to new information with instant curiosity. Some people sometimes react with instant rejection. The latter, whether verbally said or not, is what makes it harder for us to receive Feedback and correctly interpret it.
Changing someone’s mind is very hard to do. To avoid hardening of mental models, would be first avoiding the need to soften those. And that is to avoid the Details as much as possible.
In the next chapter, we’re going to take the idea of avoiding Details to the extreme. Have none whatsoever! and let everyone do whatever they want or need!
I hope you find this idea horrific as I am, because the next chapter is about Restrictions.