3 Principles for Software Engineers Building New Products
As a software engineer, I have found the following principles useful when building new products. Note that these may not necessarily apply to scaling/making changes to existing products.
1. Be lazy
Try to avoid solving problems of the future. If you hear a stakeholder say “This will not work when we have to scale this to N users/languages/regions”, just smile, appreciate their optimism for the product and track that as something to be fixed in the future. In general, always think long term (where the product should be months/years down the line) but only execute on things that will have an impact short-term. By focusing on short-term goals, you generate learnings more quickly that can potentially change how you think about the long-term. Because you invested less for those learnings, you reduce the sunk cost when you change direction from those learnings. In an ideal world, the short-term goals will help you take a linear path towards the long-term goal. But the reality is more like a zig-zag path due to the unpredictable nature of product development requiring plenty of deviation along the way.
Once, my manager and I were in a meeting with another team who demandedthat we make changes to our team’s systems to support a new product launch that was happening in a year. After patiently listening to the requirements, we walked out of the meeting. I was very worried about all the additional work we needed to do to support this and mentioned this to my manager. But my manager was very calm and then shared his simple rule-of-thumb to assess whether a problem is worth solving right now:
“Things change a lot in software development, so don’t worry about anything that is more than 6 months away.”
I was very skeptical when he first shared this with me but this has been consistently true in my experience so far.
Fun fact: It took more than a year to launch the product and the requirements had changed significantly so we didn’t have to make any major changes to our team’s systems.
2. Be pessimistic
When building a new product, think about all the things that could go wrong and use that to either drop some features and/or reduce scope/prioritize the riskiest pieces first. A rule-of-thumb that I use when estimating the ROI (return-on-investment) of a feature is to double the expected effort (mostly dev time) and halve the expected impact (metric changes). If after applying this pessimist correction factor the ROI still makes sense, you can proceed with the work.
My preferred tool for thinking through all the things that could go wrong (so they can be proactively tackled/avoided) with a new product is a premortem. It is fairly common for teams to do postmortems for failed products to understand what could have gone better. A premortem is a more pre-emptive version of this process where you assume the product you are building has already failed and you try to identify all the possible causes up front. This is a great tool that allows people to put aside their inherent optimism and put on their critical thinking hats to be their own worst critics. By framing this as a constructive self-improvement exercise, this process creates a safe space for team members to express their concerns (fact: everybody has concerns that they don’t share) without any judgement.
3. Hack it
I love hackathons. They act as a forcing function to help you reduce scope and build a working product in the least amount of time. Applying artificial time constraints helps fuel creativity and find solutions that you didn’t think existed. So, taking the same philosophy and applying it to regular product development can be valuable.
When thinking of building a new product/feature (once we have established the need to build this), the first question in my mind is:
“If we had to build this in a day, how would we do it?”
This question helps articulate a lot of assumptions that you may have about the product and identify blockers to an initial launch. By challenging some of these assumptions, we can reduce scope significantly i.e. deciding which features are must-have vs nice-to-have. The follow-up questions that drive this conversation are usually of the form:
“Do we really need feature X? In the short-term, can we do Y instead where we don’t have a dependency on team Z?”
Reducing scope aggressively and getting a first version out quickly helps the team focus on validating core assumptions. This allows you to get one step closer to answering the more existential questions surrounding the product (“Does anyone WANT this product?”). Seeing the first version of a product also helps with team morale and retaining trust of key stakeholders which more often than not determines if there will be a second version of the product.
To summarize, building a new product is a messy process with a lot of unknowns. You will constantly learn new things that will help shape the product. So, the goal should be to optimize for gaining those learnings in the shortest possible time.
Special thanks to Jessie Duan for reviewing earlier drafts of this post and making it readable!
