Architect thinking: Peeking into the product’s future
I have this habit of asking product managers questions about whether or not customers will need a particular feature in the future. Product managers are at the forefront of customer needs; I believe engineers need to see what they see in order to make sure our technical decisions are informed and correct.
When asking questions of this nature, I expect to get one of 3 types of answers:
- No, not now, but never say never
- No and here’s why
- Yes and here’s when
No, not now, but never say never
Other versions of this answer could be an abrupt “no” or an “I don’t know.”
I interpret this type of answer as: we/engineering should still think about how our systems could evolve to support this use case when we learn more about our customers’ needs in the future. If we find that it would be a massive system change/rewrite to support this, I’d either spend some time assessing if there’s a possible refactor that could build in some flexibility (best case supporting a different feature we know we need to build) without violating YAGNI (i.e., contorting our system for a future that likely won’t happen). Or, I’d ask product managers, data scientists, and/or user researchers if there’s any way to get more information from customers (their opinions, current behaviors on our system, or the way they behave on competing platforms) to educate us on the likelihood of this being a possible future.
If it’s expensive to build in flexibility or it really feels like a YAGNI, then I’ll raise this possible future cost to accountable leadership so they know that our delivery speed will be impacted should this need arise.
No and here’s why
This is a great answer since it comes with a justification from the customer, though, I usually accept it as a 95% no. I think that 5% skepticism is healthy just in case the product manager turns out to be wrong over time. The worst case outcome to avoid is that engineers point fingers (“you said it was a no!”) and get frustrated when they have to comb through each system and do heavy changes to support the new reality.
With this answer, I won’t design for that feature and assume the rationale to be a hard constraint of the domain, but will keep it in mind as a possible risk.
Yes and here’s when
This is the best case outcome, but happens infrequently. It’s a win for asking the question and a win that we know this is a need that hasn’t yet hit our backlog or roadmap.
You have a couple of choices on how to proceed thereafter:
- Make sure your short term decisions don’t work against that upcoming need.
- Communicate/document this insight so engineers are informed, but risk newer engineers (that didn’t hear you or didn’t see the documentation) building based on assumptions of the current state of the product making that future state more expensive to get to.
- Consider building in the flexibility you’ll need from now. But, be comfortable with that future possibly being far away as priorities change or that product manager being wrong. You can derisk this a bit by assessing how expensive it is to back out of this flexibility and use that to judge if it’s worth building this now. The benefit of building it though, is that you don’t have to rely on engineers perpetuating a possible future as the company grows.
You may find that newer product managers tend to be put off by this line of questioning: thinking it’s putting the cart before the horse. However, as a product engineer/architect, peeking into the future is an essential skill for de-risking your architectural decisions and avoiding future pain.
