Negative feedback
I’ve collected some of the worst feedback we’ve received, mostly for stuff under my responsibility.
- User: “ROWS is a joke. A spreadsheet app that can’t open CSV? What genius thought that one up? I didn’t even evaluate the actual app. Who has time to retype data? Good luck competing with Excel and Sheets. You’re going to need it.” (2022-03-25)
- User: “So, your company wants to compete with Excel and Sheets and you don’t have the functionality to import CSV files? A spreadsheet app that doesn’t open CSV files is a piece of shit. It’s useless. You’re going to fail miserably with your current leadership. You need someone who ACTUALLY uses spreadsheets, and you need them quickly.” (2022-03-25)
- Team: “I think we’re missing Focus. Too many meetings. Too many distractions. The devs are great, but the Dev/PM and Design/PM discussions are slowing us down.” (2022-08-25)
- Team: “No clarity of functional responsibilities, except Engineering - e.g. PMs responsibilities were questioned a lot and changes were constantly made - P.Design deciding product, (Humberto) saying “everyone can be a PM or do Product.” (2021-03-12)
I have 2 guiding principles to parsing through feedback:
- Thank it. I generally take it quite to heart, but 99.99% of negative feedback isn’t ill-intent. The most negative comments result from deep frustration in my experience. Thanking feedback is important to acknowledge the other side, and is a way to extract more info.
- Own it. Most feedback comes from the consequences of decisions that have to be made. Negative feedback means that something that is important to a user or colleague got left out. If I’m convinced think that this wasn’t a big problem, I recognize that there are trade-offs and that I am comfortable with their consequences vs. the effort to improve it. Otherwise, I assume that we actually have failed and that it is important, and I work on a plan to get a fix.
- Close it. It’s important that every piece of feedback is closed and that everyone involved understands the final state. Will you fix something or maybe not? Why? In my experience, being a passive inbox of feedback and not closing the loop amplifies the negativity.
You will also get positive feedback, and that helps along the way!
- User: “Rows is an objectively well-designed software, I’m pretty certain if a user is thrown into it right away they will appreciate the quality and value prop. They will appreciate how much better it is than Sheets/Excel.” (2022-08-01)
- Team: “I really loved everyone. My job at the Apps team (…) it was amazing. Everyone on that team was very motivated.” (2022-08-25).
- Team: “People - amazing people, low ego. Having so much space to decide technologies, way to go - a lot of trust in Engineering.” (2019-12-19).
Over time, if you do a retrospective, you can also get a pretty accurate picture of what organic system you have on your hands.
- at Rows, user feedback can be summarized as “I think this is amazing, but YOU MUST improve X”. X has varied a lot in the past, and nowadays its just a couple of items.
- team wise, if we mash the feedback I think we get “the vision for a next-gen Spreadsheet is very ambitious, and creates a clash between our values of Focus (speed) and Boldness (10x vision), which affects Product and Design. We all want more success.”.