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 principle of The Iterative Roadmap, to avoid and postpone the Details as much as possible. We’ve seen it is beneficial to do, a better way to set expectations that avoid disappointments.
In this chapter, we’ll deep dive into the Details themselves. We’ll see why they are another source of 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 needs. We’ve even contacted them 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. A Deviation has been created, one that entails Changes to past work.
The reason for this Deviation matters less, because a lot can change and happen in 4 months. It could have been a Feedback given, because we’ve left an opening to get one. It might have also turned out PayPal no longer fits the business/customer needs.
So even though we used a Roadmap, which is supposed to prevent future inefficiencies, we may have ended up with unawarely coding Blockages and potentially changing the entire product design, UX and technical, past and future. All because the entire Roadmap was based on one very specific Detail. One Detail that has mentally locked us into it and tightly coupled our code and design to PayPal. One Detail that has created the potential to Change everything.
And this could be avoided by postponing a decision as much as possible, maybe up until the very last minute. It would give the largest opening possible and the time needed for external events to eventually rise, such as the imaginary Stripe discount. A more informed decision requires more information, out of Feedback or further research. That is time given to do exactly that. To first do this, and only then to fulfill and finalize the coding/design.
Detailing less could dramatically reduce or completely avoid Changes. Just drop the name PayPal from the design and the Deliverable name. Leave it at “Integration with a 3rd Party Payment Vendor – To Be Decided”. That is the technique to postpone a decision and to force the code and the design to be agnostic to it. Which is how a Blockage would be avoided, one that need not be removed 4 months into the Roadmap. It would also not need to be removed 5 years into the future. Details create potential inefficiencies. A Roadmap with less Details would be more beneficial.
Details affect product managers and designers as well. It was the Details that have caused RapidAPI’s designer to continuously update the product design, the problem we started this series with. I’m not a product designer, so I can only suggest it would mean to keep some of the design as a wireframe for a while.
Emptying Promises
Roadmaps create expectations to be carried out on time. Other expectations are set by 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. These are the outcomes of Roadmaps with too many Details, and with promises done 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”. It sets an expectation that there will eventually be one. So when the time comes, whichever we decide would not create a disappointment, because we did start with setting a firm expectation to which one.
And if we notice carefully, we can even better set it when needed. Because, we presume ahead and promise that we’d actually need to automate payments. We need to keep our minds open to other possibilities. Maybe when the time comes, for some unexpected reason it would be needed or more beneficial for the payment to remain manual. We could instead set the expectation be “we are going to resolve the need for payments”. The need itself could also be the minimal Detail described in a Deliverable or a design. Because a Roadmap’s goal is to prevent Blockages of future needs. Same goes for the product design.
At some point, we’d need to further detail the Details. They will probably not remain minimal forever. But we can choose when to do so. Months in advance creates more potential inefficiency because the sooner it is, the more uncertain it is and the more likely a Deviation would occur. The optimal timing would be to elaborate the Detail exactly when the necessity to fulfill the need rises. Realistically speaking, it should be as close to it as possible.
Notice the expectations we set are not for trying. We should not “try to resolve payments”. We do not try. We manage and set expectations and get them done. More reason to consider the possibility that we’ve gotten the need all wrong, or end up not needing it at all. This creates a potential disappointment in everything we’ve done. I’ve been there, don’t go there. To avoid even that, we can set the minimal expectation to be “we are going to explore the need, if and when it rises”. It does not contradict discovering those needs, predict them and don’t be surprised by them. This can be done at any time, as long as we keep the Details for when the time is right.
And that is exactly what The Iterative Roadmap is doing for us, it is built with the principle of postponing the details. It gives us that needed flexibility. And we would later see that these minimal expectations are the building blocks of Long Term Roadmaps.
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 which we need to overcome in order to make a needed Deviation 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 is 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 manufacture. It was on “this is the future sales pipeline”. The rest were kindly asked for our opinion, but it was already too late for that.
As I have scraped hundreds of eCommerce sales pipelines and had some experience in product management, it was easy for me to point out the faults of the suggested one. It consisted of 7 different screens, one of them you had to click about 12 different buttons and dropdowns in order to customize your order. Which was mandatory. And the final blow was that you must register and login before you 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”. I believe they’ve worked on it for about 10 hours, down to the very last Detail. 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 are the ones to make this bond too hard to sever, which makes it harder for us to Deviate when needed. 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. And the more Details the existing mental model has, the new information is less likely to overlap.
Some people sometimes react to this 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. When that happens, in order to change someone’s mind, mental models must be softened first. Which is sometimes hard to do. All the more reason to postpone and avoid Details as much as possible. By Detailing less, we avoid hardening theirs and our mental models, which avoids the need to soften and overcome it later.
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.