Reflecting on my first startup job: Part 2 - Regrets

18 August 2014

(This is part two of my series reflecting on my first startup job. The first post, about surprises, is here.)

Part 2: Regrets

Overall, my experience at the startup was great. I learned some invaluable skills (including how to code) and worked with some really cool people. Although I don't have many regrets, there are some things I wish I had done differently.

Should've focused more on the user

As previously mentioned, our startup was a very quantitatively-driven one. At the peak, we had dozens of split tests running at the same time, each tracking dozens of metrics that we "cared about" (in reality, it's hard to care about so many metrics simulataneously). We even had our company's key metrics (user count, user engagement, revenue) up on TV screens. In retrospect, I think all this attention on the numbers drew a lot of attention away from equally important qualitative feedback from our users. We tried a few times to ramp up user feedback testing, but we never developed a good system for it that we were able to stick to. We were stymied at almost every step of the feedback collection process - how to find interviewees, what to ask them, how to phrase the questions, how to organize the feedback, etc. This was a daunting set of questions for us partially because no one person was responsible for gathering this kind of feedback. As someone who spent all of his time working on the product, I feel partially to blame for this lack of attention, and wish I had pushed through a long-lasting, full-fledged solution.

Should've kept stretching myself to learn

This company taught me how to code. When I started off, I had almost zero technical background, and within just a couple of months I was working like a developer. After a while though, my "real" projects caught up with me, and I wasn't spending time learning about new technical areas. Since almost all of my projects were focused on building new features for the product, that's what I spent most of my time doing. This is a real shame because there was a lot I could've learned from my coworkers, from design skills to back-end systems knowledge. Although I certainly kept learning on my job, at some point I let my learning curve become less steep, when there was still so much more to learn around me.

Should've been a stronger voice in product discussions

I spent all of my time working on the product, and by the end of my tenure, specifically on the core product. My days were filled with running tests, building out new features, working with different stakeholders, and trying to think of ways to improve the product. Reflecting on the times when I was in meetings with our CEO, I probably could've been a stronger voice in discussions about new ideas or directions to try. When asked, I would give a (hopefully) reasoned, supported opinion, but I probably could've communicated my ideas and higher-level thoughts more often, more proactively, and more clearly. One example of something I should've spoken up for earlier was the point about gathering more qualitative user feedback.

Should've just refactored code that was old or flawed

Since our company has grown and changed a lot in its lifetime, there are a few areas of the code that could use some serious refactoring. These areas were ones that everyone knew could use some love - the ones people "didn't want to mess with", the ones that didn't have great test coverage, or the ones that hadn't been touched in a while. In hindsight, I should've just tackled some of these refactorings myself when I had the time! This is especially true for the parts of the codebase that I had the most interaction with.

Should've been more clear about what role I wanted to develop into

My position at this company was one that was officially vague. It was squarely in the engineering team, but was one that allowed the holder the chance to develop in whichever direction he or she wanted, whether it was further as a developer, as a product manager, or even as a data scientist. The freedom of this role is what allowed me to try a bunch of different things at the beginning, and eventually settle on product-focused projects. When I decided on this, however, I should've re-evaluated my position and tried to work out exactly what skills I wanted to learn. When I decided that I wanted to develop the product management skillset, I should have communicated that earlier to the leadership, and figured out ways to make that happen within the context of our company. In hindsight, I sometimes wonder how my trajectory could've been different had I started gunning for a more official transition within the company, even though we had never had a Product Manager before.

Coming up next in the series: lessons learned about the startup world.

comments powered by Disqus