Follow-up to “product feedback cycle” post, this time from engineering

The following is a follow-up to my post on the “product feedback cycle”.  This post was inspired and written mostly by JJ Geewax, who was/is our VP of Engineering at Invite Media.  He has been with us since the beginning, so his perspective is well ingrained in what we actually experienced.  He brings up some great points not to be left out when looking at this concept as a whole across the entire startup (particularly engineering).

——-

I think there’s something important to point out which might have been outside the scope of the original post.

To start, when looking at the product feedback cycle, the most successful products seem to result when engineers are involved in the problem-solving part of the product.  The goal of this post is to breakdown what that involvement means.

First, at Invite, we do what’s called “context meetings”.  These were especially important early on when business and technical context was more required and everything was still in flux, as explained later.  These meetings helped the product process and were great for a few reasons:

1. Founders would get down and dirty in the implementation. Even if they didn’t understand all of it, they needed to develop an idea of how it was going to be done. This kept them from thinking of engineering as a room full of monkeys on treadmills running faster to get more stuff built.
2. Engineers would get to hear the business problem from the person dealing with the business: “Our clients want to do X because they have all this money and would love to spend it in this way.”  Most of the time Zach (one of our co-founders) had an idea of how this would be built technically, if it involved UI Nat would design/mock it up, and most of the time it was pretty close to what the engineers were thinking as well, but taking the engineer on “the journey” gave them a better understanding of what the client wanted and better equipped them to build the thing and ask the right questions along the way.
3. The entire engineering team is *not* in the meeting, but there are enough heads involved to cover most of the cases. Occasionally someone would hear about the solution and say “wait, why not just do X”, and most of the time the answer was “yeah, we thought about that and we can’t because of Y”. Very rarely did that make us do a full 180 degree turn, but the “presentations” soon after the meeting explaining the feature to the entire team short-circuited that as soon as possible.

We had some experience before practicing the concept of context meetings, and learned a lot of things the hard way.  Specifically we saw the following:

1. Engineers rebelling because they feel like they were less involved in the decisions on what the clients actually want.
2. Engineers seeing that the decision is right but fighting for an alternative simply because it was shoved on them by product managers (“arguing for the sake of arguing”), which isn’t something only engineers could be led to do.
3. Engineers having to justify engineering decisions to product people, which at Invite were the founders in the beginning. This leads to tons of frustration trying to explain “No, XYZ Technology can’t be used in the same way we use ABC Technology”, and does nothing to foster a sense of trust on either side. 
4. Product people being accountable for the feature instead of engineers, but engineers responsible for doing the work, leading to some level of micro-managing in the form of incredibly frequent and detailed check-ins (not ideal for productivity)
5. Engineers losing motivation as their work feels more like being a “glorified typist” than an engineer. The fun decisions are made at the product level, and the low-level decisions that are could be perceived as stupid or obnoxious are all that’s left.
6. Engineers lacking a feeling of ownership and responsibility, leading to a lack of care when something breaks, or testing fails, or clients aren’t happy. “Who gives a crap, let the product people fix it.”

I think we found a happy-medium with a short meeting with 2-3 engineers and 1-2 product people where the engineers in the room were the “official owners” and the product people started the meeting by explaining the problem and why it mattered. This gave people (1) a feeling of ownership and a way to take pride in their work, (2) let product people focus on “the next big thing” instead of nagging on engineers to find out when the last thing was going to be done, and (3) kept the engineers far more engaged in the product and on “what else” they could build that product people might not have realized yet was really easy. Engineering owners also were far more interested in fixing things when something broke — after all, it was THEIR code and THEIR decision, and now THEIR reputation is on the line if this doesn’t work… Plenty to be said for proper chain of accountability.

As mentioned before, context meetings were critical for us in the beginning when the product/market fit hadn’t yet been nailed and everything was still very much in flux.  As things solidified and as the rest of the team started to understand the entire context (both engineering understanding the business context and the product people understanding the tech details), you can graduate into shorter meetings that focus exclusively on valuing the revenue impact of certain features, for instance.  

There are tons of positive side effects from this cycle as well, such as (1) having founders (who as discussed in the prior post should be the product people) who are forced to understand the tech details, which allows for much better planning and sales ability, (2) engineers who know the business details and are trained on the business and could jump into other facets of the business or manage teams more effectively in the future (leading to an engineering culture and DNA, which is never a bad thing), and (3) a much more connected team that communicates often.