In the race to launch products, the finish line is a starting line

Are you sitting on an idea for a new app or digital product? If so, congrats. It’s an exciting, if not slightly scary, moment where “what if?” is intoxicating, and “what’s next?” looms large.

If you follow the proven playbook, you’re looking to sprint through several phases of product development ahead of launch: You’ll rapidly prototype your concept, so that you can test and validate it with potential customers. Based on their feedback, you’ll iterate on the design until you have the right mix of features. Once dialed in, you’ll build it and launch it — but, not without a go to market plan. Which means, while doing all of that product development, you’ve simultaneously created a compelling story-led brand strategy for your sales deck, digital marketing, etc.

It’s a lot, to be sure. And in these early days, ambiguity and complexity will try to slow you down at each turn. 

So far, we have just been talking about getting to launch. But here’s an even better question for you: how quickly can you launch and land your first customer?

‍Recently, our team did all of the above for Vela, a new B2B SaaS venture in the commercial lending space in about five months.

It’s not the first, or last time we’ll have a headline like this, because getting innovative new technologies off the launch pad with focus and speed is how we make a living. That being said — I’d love to shed some light on how we pulled it off, so that the next time you’re looking at a product roadmap you have some ideas for how to hit fast-forward. 

‍

Challenge One: Nail the Problem

Going from a blank slate to a market ready product launch in five months is a sexy soundbite, but it’s not the whole story. In reality, creating that kind of velocity and output in such a short amount is only possible when the team is aligned on a clear problem.

In the case of Vela, our Insights & Consulting team began by interviewing lenders, loan assistants, borrowers, and executives to identify common pain points. Next they generated preliminary product concepts for initial testing and validation. These concept demos were accompanied by a provisional pitch deck, so we could use those conversations to also validate the positioning, value proposition, and brand story. After all, what good is a well-designed product, if you can’t convince people to buy it?

This might sound like a lot of time and effort to spend on discovery, with no product yet in hand. In some cases, it is. But there is no one-size-fits-all approach to validation. In the case of Vela, we knew from the outset that we needed to get initial validation in order to secure additional funding for the full product build. In a space that hadn’t ever seen our proposed solution, the risks were high and needed to be managed accordingly.

After many iterations of the problem statement and concept we found a fit across our interviews. There was an opportunity and appetite to dramatically improve the commercial lending experience by simplifying the process for requesting and collecting the mass amount of documents and information needed for each loan. 

‍

Challenge Two: Narrow the solution

Our Insights & Consulting team had done an exceptional job of sniffing out the right problem to solve. But in doing so, uncovered a lot of opportunities for how we could improve the experience. However, the challenge we now faced was deciding which of them to prioritize. We had to decide what was going to create the most value for our users, and focus on delivering the best version of that. 

We find ourselves in this position often. And through this experience, have developed reliable (and fun) methods for aligning stakeholders on the “most important thing.” In this case, we had a big, untested idea in a space with no real forerunners - a pretty big risk to manage. 

Enter the prototype sprint. 

It’s a proven process that we’ve relied on many times to generate innovative results. And as the name implies, the pace is swift. Whatever speed you’re imagining is too slow. Picture, if you can, five full days of highly choreographed creative workshops where we go from a blank whiteboard to a full blown prototype being tested with our end users.

When you timebox an effort, and limit that time to five days, it’s impossible for anyone to lose interest. It’s also remarkably fast (by most organizational standards) to complete any project, let alone develop and test a prototype from scratch. So the perception of time dragging on, and resulting frustration, are non-existent. And the speed at which visible progress is made each day is not only gratifying, but exciting. It’s also a neatly self-contained process, so decision makers know precisely how much money and resources are needed to reach a definitive result. 

There’s also an interesting thing that happens to the participants in the room. The pressure of knowing how much ground you must cover, in such a short span of time, has a way of hijacking everyone’s normal thought process. You will never experience a more creative, efficient, or decisive version of yourself than when you’re collaborating in a design sprint.

The design sprint for Vela produced the desired result. We went home at the end of that week with a clear vision for this new product, a prototype representing the core aspects of the experience, and user feedback, telling us that we were not only focused on solving the right problem, but were solving it in a way that acknowledged their needs and preferences. We left those interviews hearing people tell us that they would use this software, if it were available, they would be willing to pay for it (and how much) and share ideas for other things they would like to see it incorporate. 

‍

Challenge Three: Maintain momentum to launch

Our challenge now was to maintain all of the momentum and enthusiasm we had just generated with the sprint. We needed to find our next catapult. Something that could help us leapfrog to our next significant milestone. We decided to organize a hackathon, otherwise known as an engineering sprint, to create a working proof of concept as quickly as possible. Much in the same spirit as our design sprint, we felt a hackathon was the shortest and most direct route to getting a working version of this concept in our hands.

The two weeks that ensued saw four of our engineers swarm around this initiative with undivided attention. Over ten days they would focus on building the core underlying functionality for this product. It would not be perfect or complete, but it would prove out that we could do it, would help us quickly spot unanticipated challenges, and help us maintain the momentum we desperately needed. 

And it did just that. By the end of two weeks, we had enough functionality coded to serve as a foundation for the remainder of the build effort. We had a better idea of what our build scope and technical complexity was going to look like, and were able to clearly plan out our delivery schedule for first release. 

Doing this got our team to a critical juncture in the project - the engineering delivery cycles. Unlike the “fuzzy front end” that we had just navigated, we were now locked into a clear definition of what we needed to build. From here, it was just a matter of executing. As long as we maintained our schedule and output, there was far less risk of losing momentum.

When Vela was finally launched, there was still plenty to do. However, we had the core value-creating features baked in. And it was clearly enough to meet our customers’ minimum threshold, because we signed our first contract in a matter of days after launch. 

Don’t get me wrong. Vela is only two months in, so the risks are still plentiful. But we have a lot more clarity around what customers want, and a lot more confidence in our ability to pivot when the time comes.