Transitioning to the new process

Our team was really supportive of making this change. Their openness to doing something new and willingness to wait and see the potential benefits were greatly appreciated and helped make this a success.

We had a couple of challenges, all of which were overcome. Initially, for our junior engineer, it was hard to make product proposals as he hadn’t yet spent time with our users. To remedy this we offered him our own suggestions and introduced him to users he could talk with. Over time he built up experience and was then able to make good product proposals.

Secondly, it’s harder to track if the team are on target or not — everyone is in a constant cycle of technical and user discovery, and as we learn our plans change. Sometimes features we think will be small turn out to be much bigger. To combat this I regularly check-in with our team, asking what their goal for the day is. Then, we quickly assess if their current plan’s effort-to-reward (i.e. ROI) seems appropriate, and if it doesn’t, suggest a small adjustment to the plan.

Finally, there is a risk with this process that you lose product design quality. This could happen in two ways: the UX of individual components could be worse as the engineer designing them lacks a background in UX design. Secondly, the overall platform could lack coherency as its different pieces are designed by different people. We’ve combatted this by having UX review be required on all features, just like code review. Engineers receive code and UX feedback on their work before it’s released. Also, as product manager, I share sketches of how the platform could look in the future and help guide everyone towards a shared vision.

The benefits of adopting the new process

“I was initially hesitant to move to engineering led product prioritization. I thought our product would become disjointed without top down prioritization. This did not happen. Instead I’ve seen two big improvements: First, the team is more motivated — people are working on what they believe is most important. Second, the features we build are better. The engineer understands the problem in more detail, and iterates with the user to ensure that it solves the problem they have. Overall this has been a great change for SketchDeck, and we have a better product as a result.” — Chris, CEO & Co-founder

After making this change, I immediately noticed how much more time I had to code, as I no longer had to spend so much time project managing. Thanks to the new process I doubled my code-writing volume:

My GitHub commit volume over time

The next benefit was that our snag list began to shrink after being backlogged for half a year. In the old process, it was too much work to prioritize tiny fixes, so we didn’t get to them. Now, as engineers bumped into snags they’d fix them, then carry on what they were doing:

Our engineers’ technical and product decisions improved:

“A major benefit is in the responsibility that an engineer feels towards the success of his output. After several cycles of claiming to understand a users pain, and advocating a solution, one tends to become very honest about the real effects of features being developed. The more direct the feedback loop from real users, the better” — Kris, Senior Engineer

Instead of somewhat grand and circuitous technical plans, engineers opted for quick fixes and tactical hustles. We still work on architecture projects, but are more considerate of their big cost.