Using Feedback Loops to build Great Products

In my Product Management career, spanning from Zynga to Earnest to now BlackRock.. with a handful of startups mixed in, I’ve found feedback loops invaluable in managing the complexities of product design, iteration, and ultimately shipping. It has also been very helpful to me as an abstract concept to determine the best communications architecture for a collaborative team.

To start off, what are these “feedback loops” that I’m referring to?

Lets see what Wikipedia has to say:

Feedback occurs when outputs of a system are routed back as inputs as part of a chain of cause-and-effect that forms a circuit or loop. The system can then be said to feed back into itself. The notion of cause-and-effect has to be handled carefully when applied to feedback systems.

Wikipedia also immediately mentions the following about causality in a feedback system, but we are getting a bit ahead of ourselves ;)

Simple causal reasoning about a feedback system is difficult because the first system influences the second and second system influences the first, leading to a circular argument. This makes reasoning based upon cause and effect tricky, and it is necessary to analyze the system as a whole.

In my PM-ing career, I’ve shied away from the PM-at-the-center-of-the-universe philosophy. This is mainly because, I feel that this philosophy taken to an extreme and applied across a Group of Product Managers leads to sub-optimal outcomes for large companies (especially for Non-PM employee morale).

In line with this philosophy, it really does not matter that much to me whether I’m able to pin-point the causality of an outcome (perhaps for optimal reproducibility) as much as it is important for me to help my team achieve the best possible outcome. Perhaps this is a little naïve, and not the best approach for maximizing “personal” career success (often at the expense of the best outcome for the company) but this is how I’m wired and its a bit hard to change.. this late in the game.

This is another reason why I’ve leaned in on feedback loops as a useful reasoning tool when trying to deal with the product management process.

I’ll now outline the design and development process I typically champion along with some prescriptions on when to move on to the next step of the process. OK, let’s jump right in.

Design Loop

When working with designers, it is key to give them all the freedom they need to apply their “design thinking” chops. You should start with a problem set of what you are trying to solve for the customer and let the designers first come up with the best possible way to solve for that need.

After the first design iteration, it is important to regroup as a team and loop in engineering and product to evaluate constraints (internal and external) in achieving that solution.

Constraints can be of many kinds: For a startup, revenue/cash constraints are more important and sometimes, depending on your geography, engineering time may or may not be a constraint. Typically, you have the trifecta of physical, time, and intellectual resource constraints. These are usually internal and then there are market constraints to think about as well:

1> Where is your product in the market?

2> What will the competitive response likely be?

3> How is the market/industry evolving?

All of these are going concerns for the PM, and need to be factored in when making a decision about the design of the product.

When working with designers make sure you listen to their feedback. It is easy to cut people off because PMs are busy people, but practice the art of listening to designers as they can sometimes come up with simpler and more elegant solutions than you imagined since they are not working up from the assumptions and constraints that you know about.

Engineering/Prototype Loop

Once you have a sense of the design for the product, the next step is to work on an initial prototype. I have found that generally starting from the user experience (frontend) to design the backend system(s) is more user-focused but lacks flexibility.

If your target market is large, this might be OK but for smaller startups with designs that are in flux and target markets that are initially small, designing around flexible and abstract backends is more useful.

This is due to the fact that abstractions lend themselves to easier adaptation of the frontend designs you may have in the future. This is one of the reasons Facebook’s hack around SQL to get graphQL worked well and now is a core part of the React development model on their frontends.

Each MVP should involve tight feedback between the engineering and design teams with Product Management guiding the direction while keeping market realities in mind.

Demo Loop (stable product)

Once the MVP is in good shape, PM’s need to work closely with marketing to establish how the product ought to be sold in the marketplace. This involves messaging, ads, positioning etc. Usually for this stage of the product, having internal demos helps crystallize the value proposition and brand message.

Actually having to demo something in front of an audience (even if internal) helps cut through the noise and focus on the areas that matter.

Ship it!

Done :)

Summary Diagram