Building products at an early-stage startup is a constant fight with uncertainty. Big companies typically have carefully planned out roadmaps. But at a small, early-stage company, you’ll likely build things that never come to fruition.
We spoke with Shawn Vo, CTO of fintech startup Denim (previously Axle), about the uncertainty that startup engineers face when building products.
He shared advice on how to keep your engineering team motivated, create a product roadmap, and manage technical debt when facing uncertainty.
Table of Contents
Why startup engineers should plan for uncertainty.
“I would say that by definition a startup is a company that’s in search of a scalable business model. There’s uncertainty baked into what you’re doing.”
The amount of uncertainty is often greater for startup teams simply because they’re establishing a core product, testing product-market fit, and building a customer base.
It’s important to embrace the mindset that what you believe might not be true. Vo explains that prior to launching Denim, his team pivoted in significant ways and experimented with different technologies: “Most of what we built got scrapped. We had to stay flexible and open-minded when abandoning ideas that we originally thought would be worthwhile.”
Vo further explains that most engineers hate the idea of writing throwaway code. When you’re not sure how much the product will be used or whether you’re building the right features, you have to plan for some level of wasted work.
How to keep your team motivated in an uncertain environment.
Prioritize Transparency
“The biggest thing is transparency. That’s how you build trust with your team. If they’re fully aware of the situation, they’ll be more committed and they also won’t be surprised if it doesn’t pan out.” – Shawn Vo, Denim
Keep your team in the loop by being transparent about the uncertainty you’re facing. This means you have to be willing to tell the team when you’re taking a bet. Communicate why you are willing to try building something out even if there’s some uncertainty around it.
Make sure you communicate the vision, so they know where they’re heading. It’s also helpful to share a product roadmap with the team (more on that below).
Lastly, be sure to check in with the team. Ask if they understand what they’re building and where the team is heading. Engineers who understand the future direction of the product and team will be much more motivated to contribute.
The benefit? You gain your team’s respect and trust. It also means that the entire engineering team can contribute to brainstorming solutions together.
Note: This also applies when you’re hiring new team members. If you’re honest and transparent, they’ll understand that they’re joining a team that works with uncertainty. They’ll also understand the tremendous upsides that it can bring for their career.
Focus on What You Can Control
In order to make the most of building with uncertainty, focus on what you can actually control.
For example, you can choose to speed up a timeline by building an MVP and testing product-market fit instead of building an entirely complete product or feature. The engineering team is less likely to mind a “failed” project if they know that they didn’t spend too much time building it. And if the product is met well in the market and you prove customer demand, then you’ll be free to spend the funds and time on building out a more robust product.
Vo recommends, “Depending on the level of uncertainty, you might build things in a non-scalable way. That means you don’t capture all the edge cases, don’t write as many tests, and don’t make the code as DRY.”
How to create a product roadmap in this environment of uncertainty.
Start with a One Year Roadmap.
“In general, I like to think about the one-year product roadmap because when you raise money you generally have a 12-to-18-month runway. So you know where you’ll need to be in terms of product market fit, revenue and users. From that one-year vision, we plan out quarterly roadmaps.”
With that said, Vo explains that early on in their process, they didn’t have a full roadmap. Instead, they tended to build off intuition by seeing what would happen week by week as they launched features.
It was only after the company’s first year that the founders finally asked for a product roadmap. He notes, “I would do my best to give them at least a high-level product vision, including phases of how we could get there.”
Listen to Your Customers.
“If you aren’t changing the roadmap, you’re not learning from customer feedback.” – Shawn Vo
When your company is at an early stage, it’s important to build your roadmap in a flexible way. After all, you’re learning as you go and your environment should inform your business priorities.
Vo recommends, “Start with measurable business metrics that you want to impact. Then figure out the projects that can get you there and how it fits into your long-term product vision. Once you have that, it’s a matter of sequencing (building things in the right order) and resourcing (making sure you have the right people available to execute).”
Note: If you’re new to building a product roadmap, here are some resources to get started:
- The Jobs to Be Done Framework: Outcome Driven Innovation
- Basecamp’s Book, Shape Up
- linear.app: for project management and issue tracking
How to manage the technical debt that can come from building with uncertainty.
While it often has a negative connotation, there are valid reasons for engineering teams to take on tech debt.
Technical debt is one of the downsides of this world of uncertainty. When you build something, you want it to be reliable and fully optimized. But when you’re in that experimental phase where you’re building a product or feature concept, it doesn’t necessarily make sense to invest a lot of time and effort. At that point you don’t even know if the product or feature will last for the long term.
Vo explains, “The way I typically think about tech debt is it’s almost like a credit card. It’s convenient because you don’t have to pay your bills until the end of the month. However, you don’t want to roll your balance over because that’s when things start getting out of control. If we’re building features on top of a system that’s already carrying debt, we’ll try to pay that down before we build anything on top of it. There’s still a level of debt at any given time, but I try not to compound the debt over time.”
Conclusion.
While building with uncertainty comes with challenges, learning to work well in that environment will allow your team to quickly succeed.
And don’t forget that there’s an upside: for many engineers, the opportunity for experimentation at a startup provides exposure to a variety of technologies, enabling them to become stronger developers.
Use these tips to push your team forward while building in that environment.
