Arrow Concept

Short feedback loops

Feedback loops

When building a product or writing code, you should strive for short feedback loops. What I mean by that is your code or product or design should be reviewed and getting feedback from others as frequently as possible. If you are working on something for too long without someone looking at it or giving feedback, you run the risk of building something that no one wants.

For a developer, one example is to write small PRs, there will always be large PRs needed sometime, but try to have 80% of your PRs not take more than 1-2 days to be ready for review. And try to have the changes in each PR reviewed by Product and Design where appropriate. Get feedback and get it often. And have Documentation, QA, Infrastructure and Security teams involved early, so they are aware of what’s going on and they can be prepared to help you when you are ready to deploy your changes. Then get it in the hands of customers, because that is the best kind of feedback you can get. But that’s not all, a final, but very critical part is to do company demos (product or technical), so the rest of the company is aware that a new product feature or piece of infrastructure exists. It gets you and your team/product visibility and you can help someone else who might be trying to solve similar problems. It opens up opportunities to collaborate and network with other folks in the company

Building anything is an iterative process and the more feedback you get, the better the end product will be. And the side effect of this is you build a team and company where everyone is engaged, constantly talking to each other, it builds community, bonds team members and builds trust and you end up building a great team and a great product. Try it, I promise it will be worth it

© All rights reserved
x - @anandgorantala