Break It Down Now: Product vs. Engineering
Product and Leadership teams get excited by big, bold ideas. They want their teams to be visionary and think about everything the product could be. They fear stagnation and ugly, half-assed solutions. Engineering and Growth teams have an affinity for iterative and measurable releases with adequate resourcing. They fear scope creep and working for months on something that doesn’t move the needle.
This tension leads to a lot of directly opposing feedback from both sides, and it can be super hard to navigate. As someone who’s constantly trying to improve team processes, I’ll share my current philosophy on how to break down work in a way that allows for vision, execution, and measurement.
Making New Stuff
I believe Product teams would benefit from revisiting the good old MVP illustration:
The conventional lesson behind the illustration above is that you build net new capabilities via incremental, functional iterations. But as a designer, it can be hard to think this way. My natural inclination is to design an intuitive solution that addresses as many gaps as possible for users, while maintaining a cohesive and delightful user interface. Developing a larger vision for the user experience like that is a good thing, especially when you’re in uncharted territory and trying to do something new or better than it’s ever been done before. A more laidback engineer might tell you, “Anything is possible,” while a practical engineering manager might plainly say no (or groan endearingly like my former coworker). But the best path forward lies somewhere in between — in breaking up your grand vision into smaller pieces that can be independently released and measured.
I used to think I knew what this meant, but it turns out that the way product and engineering teams think about breaking up work is very different. Some of the things that seem simple can actually add layers of complex logic (i.e. triggering a follow-up question based on the user’s response to a previous question). It is definitely possible, but just like you want to design things well, engineers want to build things well. When they are given too many seemingly simple pieces of a vision to work on at once and are perennially understaffed (as is the case in many startups), the quality of the code suffers and becomes less stable for introducing new pieces of your vision.
I can’t say that I’ve perfected this process, and as our Head of Engineering Allan Beaufour says, “There’s no magic formula, it’s about good collaboration.” But here’s where my head is at on how we might bake that collaboration in when creating something new:
- Share thoughts and sketches early with engineers.
- Ask them how they might break up the work (in addition to the usual feedback on feasibility and design).
- Push them to investigate any logic and infrastructure that might need to be implemented to support the overall vision.
- Ask them to be brutally honest in estimation, factoring in the abilities of the engineers they have allocated.
- Go back to the (Figma) drawing board and mock up the corresponding releases, taking an additive approach. Each release should improve the user experience and maintain or increase functionality. This will not be as robust as your original design — do not be alarmed.
- Measure the results of each release to inform the next one.
- As you move towards your grand vision over time, know that it may change as your company’s needs and the industry changes.
In the words of Voltaire, “Don’t let the perfect be the enemy of the good.” Remember, being a good designer is not about making perfect mockups to post on dribbble, but about making things that actually work for people.
Making Stuff Better
Of course, we’re not always working on new stuff. What about when you’re looking to optimize an existing feature? It may be tempting for designers to rejigger entire flows in the name of usability without pausing to think about the ability to measure their impact. Even with the due diligence of usability testing, one can’t be entirely confident of the results at scale. What if your brilliant new solution takes months to build and can’t be measured directly against the old one because you’ve blown the whole thing up? Worse, what if it’s beautiful but performs poorly compared to the original?
Or perhaps your new flow performs the same, but it adds a significant amount of engineering complexity. As Kris Gale, VP of Engineering at Yammer states, “Studies show that most product ideas fail to show value… A change that doesn’t hurt the key performance indicators still hurts the product because it adds complexity debt that must be paid on all future projects.”
As an example, when I started at Maven my team was interested in improving the registration flow, which included the following steps:
Product leadership suggested moving the personalization step up in the flow to engage the user early. “We should offer users something before asking for all their information. And could we also verify their eligibility first, so we don’t waste their time?” As I mocked up over a dozen different flows to incorporate this feedback, I realized that moving one step forward would cause a ripple effect of changes throughout the rest of the flow.
Once I’d gotten a consensus on the proposed new flow from Product leadership, we shared it with the VP of Business Operations / Growth. The sheer number of changes alarmed him, and he was worried about the time it would take to develop as well as our ability to measure improvements (not to mention the risk of tanking the entire registration funnel). Instead, he showed us detailed performance metrics on each step in the current funnel, highlighting where users were dropping off and why. In the end, we targeted our improvements into four independent releases based on his report, all measurable against the original baseline. Moral: First, solve for problems that are actually there rather than rely on conjecture of what could be better.
This isn’t meant to discourage you from making any changes! As a designer, I empathize with the desire to continuously improve the product experience. I simply present these examples as reasons to gather feedback from both sides early and weigh them against each other. Every situation is different, but I recommend buddying up with your data team to see where there are discretely measurable opportunities first (check out this article on Opportunity Sizing if you’re trying to figure out which to pursue or get buy-in from leadership).
If you decide to make sweeping changes, break them down into independent and measurable releases (like you would when creating something net new) then A/B test these with a percentage of your users before releasing them to everyone. Both engineers and product leadership will thank you for it.
