Feasibility check in design —Nr. 123
A simple structure to navigate the technical discussion
If you build a product and can't code, you will eventually discuss it with engineers. Usually, you share the concept, and the engineers might point out some complex parts to build. Sometimes, they push back.
This is a common dynamic in a product team. Professional and amateur designers handle this somewhat ambiguous discussion differently.
An amateur designer will be disappointed if they have to adjust the concept because of the technical challenge. They might be mad. This is why you see a lot of jokes in the industry where designers share how engineers always say no to good things.
As a result, the designers understandably feel defeated because they can't achieve their perfect vision. However, this can lead to an unproductive discussion because the designer usually tries to push back. The engineer then will push back even more.
A professional designer doesn't adopt this "you vs. us" mentality. A pro understands that the engineers might not always experience every part of the technology. A better to handle this is to list down the unknowns or risks.
An important note: When your team feels something is complex, it is either because they can see the simpler version or it's a new territory.
I call this a feasibility check. Bringing your concept early on to the engineers is a good idea. You want to list down the complex parts. For example, last week, I met with my team, and we were unsure how complex it is to connect multiple Google calendars to our product. We list it down. Our next step is to do a quick prototype to test how complicated that is.
An amateur designer expects the engineer to know everything.
The good thing about listing things down is that you can proceed with the discussion. Then you can team up with the engineer, "Let's figure this out and see if it makes sense to keep this part."
Of course, some engineers like to push back without a clear reason. Some engineers don't want to work hard. But for this discussion, we'll ignore this type of unmotivated engineer.
So, conduct a feasibility check next time. Here's a structure you can use:
Ideal experience: What's the ideal experience, why it's essential, and what value do we want to deliver with this experience?
Technical unknown: What's this concept's unknown or complex part?
Next step: What's the next step we can do to reduce the unknown?
PS. I have 3 more slots for my Product Discovery workshop (cohort 4). If you want to learn how to structure and use product strategy for your project, join us. I will hold one more, and that’s it for this year.