DEV Community

Cover image for Five success factors for building a new software product in 70 days
Luís Brito for Supermetrics

Posted on

Five success factors for building a new software product in 70 days

One of our product teams recently took on the challenge of building a new product in the last quarter of 2022 in roughly 70 days. From a pivoting moment to the soft launch, the journey was filled with enthusiasm, uncertainty, and lessons learned.

At the end of the quarter, our team got together in London, and we had a session to analyze the main factors that contributed to our success. The list was comprehensive, but the following five factors are what we considered the most relevant.

Set an ambitious goal early

Our team took the chance and embraced the use of OKRs. We expected it would help our team align efforts towards specific goals.
What was most beneficial was that adopting this framework helped us take a step back and think about what we wanted to accomplish as a team and how to measure our progress against goals.

It wasn't the written OKRs per se that were the most beneficial. Sure, having that written and clear enough so everyone can easily understand them was important, but the alignment created between team members during our sessions to define those goals was really the most valuable thing.

To that end, it was essential to include all team members. Everyone was involved and had the opportunity to contribute, challenge, and offer their perspectives. It helped create a shared sense of purpose and direction. After that, everyone understood what they were working towards and how their work contributed to the goals.

Setting goals is important, but setting ambitious goals is even more critical. We wanted to get 10 new successfully onboarded users every week until the end of the quarter. 10 users may not seem much, but considering we didn't have a functioning product, it was an ambitious goal.

If we were 90% sure we could achieve that goal, would that be a good OKR? Starting with a goal like that would mean delaying getting those new users for several weeks and losing the opportunity to learn from them.

We aimed for a more ambitious goal, which meant starting the quarter with a 70% confidence level and working towards building it up.

In the end, we achieved our goal. But had we finished the quarter with only 5 new users per week, would that have been a failure? Absolutely not, because that would still be better than starting with a less ambitious goal, which would probably have resulted in no users at all.

Knowing that it wasn't an easy goal to reach created enough discomfort to motivate the team. It allowed us to exceed ourselves and achieve more than we thought possible. The key is to stretch the goal enough to create a healthy discomfort to trigger this response.

Know your customers

We first thought about building upon an already proven concept. Why reinvent the wheel if Supermetrics proved that certain concepts work great and thousands of paying customers back that up?

Because the customer was different this time.

That's one tricky part of building new in a place surrounded by successful products. You feel tempted to copy past successes.
It wasn't only the platform around the product that was different, but also the user. We were fearless in challenging the proven concepts and started actively looking for ways to validate our theory.

Developing new products is like navigating a vast and unknown sea. Uncertainty is a given, and bringing clarity to the table is essential.
"Who are the customers?", "What features deliver value?", "How to validate our assumptions?", "What don't we know?" were all questions we asked ourselves.

Getting to know our customers was the first step in our journey. As there were no established customer relationships for this product when we started, we needed a better idea of who our customer was and what they struggled with.

We started reaching out and talking with as many people as possible. We began inside Supermetrics and asked the marketing department. We also asked colleagues if they knew anyone that could be a potential user. We asked our existing customers. And as we're working with a partner company, we asked them if they could introduce us to potential users.

Asking, asking, and asking some more worked great for us:

  • We identified that this product's users differed from the standard Supermetrics user.
  • Our partner knew a lot about its customers and we could build on that knowledge.

Ultimately, we concluded that we'd need to build the product differently than we initially thought.

It's tempting to jump right into building, but misguided initial assumptions and decisions may impact the team's work for months. So, even if you're surrounded by other successful products and you're tasked with building something similar, always challenge the assumption that copying a proven concept will yield similar results.

Simplify, simplify, simplify

At this point, the unknown sea was less unknown. We had a better understanding of who the customer was, but there was a chance we could still make the product too complex.

Keeping things simple is hard. It's easy to stray off course and start adding more features or components to make the product more attractive.

We joked that our product was the onboarding, which is true. We wanted to invest our time in what really mattered to the user. For us, the path to user value needed to be the shortest possible. That required focusing on the bare minimum and challenging anything that could add complexity or require additional interactions from the user.

To build simple in a simple manner is a powerful approach. This simplification mantra touches all corners of product development. It applies not just to the product but also to the way we build it. Breaking down large features into smaller ones is essential when developing software products. It helps reduce code complexity and makes it easier to maintain and update over time. Smaller features also have less code, fewer dependencies, fewer tests, and need less time to review.

Another great benefit is that it's easier to fail when you're wrong, as there is less complexity to contend with. We were prepared to fail fast and iterate.

It was especially during the design phase that most of the simplification occurred. When we first looked at the designs, we thought that it was fairly simple and there weren't many opportunities to make it more simple. But after carefully looking into every step, it was amazing to see how we could still simplify it.

The key takeaway is that simplicity isn’t something to take for granted. While it may be tempting to rush through product development, investing extra time and effort to simplify the product can save much time in the long run and reach a better outcome.

Learn by doing and avoid assumptions

Talking about problems can only take you so far. Only by taking action and gathering real-world feedback can you truly understand what works and what doesn't. By adopting a "learn by doing" approach, our team was able to move past roadblocks and make steady progress.

Building new software products comes with constraints and uncertainties, especially when it involves integrating with an external platform. We were good at finding issues but rarely made progress just talking about them. However, we progressed when we started experimenting, building a prototype, or digging into the documentation. By taking an active approach and focusing on experimentation and learning, we were able to reduce the number of assumptions before making decisions.

For this to happen, fostering a culture of experimentation is essential.
By encouraging your team to take risks and try new things, you create an environment that values innovation and creativity.
When your team feels empowered to experiment and explore, they’re more likely to take the initiative and tackle challenging problems head-on. That can lead to new ideas, fresh perspectives, and innovative solutions you may not have considered otherwise.

This approach allowed us to build momentum and make steady progress, even amid uncertainty and unknowns. We learned to trust our instincts and take calculated risks rather than being held back by fear of the unknown.

Week after week, we were able to build our confidence level from 70% to 80% and then to 90%. As we approximated the end of the quarter, it became clear that we’d achieve the goal of 10 new customers per week.

In the beginning, there are more assumptions in the air, and because of these unknowns confidence level is not great. We can think of this as a burn-down chart. As we progress, we "burn" these assumptions by replacing them with actual data. As we do this, we increase our confidence. It's a fun ride.

Build trust

Building trust is essential for any team to succeed.

At Supermetrics, we take transparency very seriously. I believe transparency and trust are closely related, as transparency is one of the key ways to build and maintain trust within a team. Transparency means being open and honest in communication, sharing information freely, and avoiding hidden agendas or ulterior motives.

Our team spent a lot of time together, especially in the beginning. Everybody was invited to every meeting, which helped us touch on many topics quickly. It was inefficient but necessary because building trust becomes even more essential when some of the team members are new. New team members may feel unsure or tentative in their new role and be less likely to speak up or share their ideas and concerns. It can create a barrier to effective collaboration and hinder the team's ability to achieve its goals.

Trust isn’t a static state that can be maintained indefinitely without further effort. So while it was important for us to focus more on building trust in the beginning, maintaining it required all team members' ongoing effort and attention.

That means constantly communicating openly and honestly. We encourage all team members to speak their minds and share their ideas and concerns. Moreover, we ensure that everyone is listening and responding constructively and respectfully.

Another way to build trust is to be reliable byfollowing through on commitments and delivering on promises. It's essential to do what you say you would and be accountable when things don't go as planned.

And in our team, everyone trusts each other’s skills. Everyone had opportunities to demonstrate their competence. Being together often in the beginning really helped us to count on one another's skills, expertise, and judgment. We could delegate tasks and responsibilities, knowing they would be handled competently.

Lastly, being supportive and showing empathy are essential to building trust. It's important to be empathetic and supportive when team members are struggling and to celebrate their successes when things go well. Helping and being there for our team members when they face challenges or obstacles encourages collaboration and teamwork. It shows that you’re invested in the success of the team as a whole.


Learn more about Supermetrics as a workplace at supermetrics.com/careers/engineering.

Top comments (0)