Whether you’re building a website, platform, tool, or application, bringing an idea to fruition is no easy feat. Let alone one that benefits your customers, and ultimately your bottom line.
Obviously there’s a myriad of variables at play that all affect your lead time to some degree. Though throughout the years, we’ve noticed the most impactful ones take place at a strategic, collaborative and organizational level.
The way teams and their work are structured, the way roadmaps are planned out, and what kind of information we use to base our decisions off of.
A reason to get your hustle on
Of course, one could ask himself, what’s the big time rush? Why should I do whatever I can to reach the finish line faster? And besides, you can’t expect me to magically halve the development time of, say, a full-fledged mobile application, right?
Those are all valid concerns. The biggest reason for getting your product or service out there as fast as you can, is pretty simple: if you’re not the one providing the value to a customer, someone else will. Whoever learns fastest, wins.
Competition in the digital or online space is fierce, not to mention dense. Since the dawn of the internet, our consumption levels of media, products, and services have accelerated immensely. Businesses and advertisers alike are fighting every second for a millisecond of your attention.
Trends are becoming more and more short-lived. What’s hot right now, might not be anymore 6 months later. And about cutting that development time in half, more on that later.
Getting started is the hardest part
When an idea is all you’ve got, sitting down to actually build something is much harder than it looks.
Usually things start from the perspective of the business: your online store isn’t converting enough visitors, the companion app for your organic food supplement business isn’t retaining enough users, people don’t understand the brand image of your clothing line, the customer support department of your software platform is begging for automation... The sad truth is, solving a substantial business challenge like the ones mentioned above can take months of going back and forth alone between different stakeholders.
Brainstorming sessions feel chaotic and vague, and the result is usually a ton of diverging opinions and undefined outcomes. We recommend running workshops instead of "brainstorm sessions" to align the whole team about the challenges, opportunities, and next steps in just 90 minutes. Here's a template we use internally and with our clients to run one of our favorite workshops, the decision dash.
In larger companies teams are often siloed off: this means they can’t work on your project on a dedicated basis, and their colleagues happen to work in another department or division.
And with complex organizational structures, comes a whole lot of red tape. Everything we’ve just mentioned doesn’t even factor in budgetary restrictions, either. Things are starting to sound a little desperate, aren’t they?
Assembling your team
Now for the good part: getting unstuck. The biggest driving force of digital product development is having a dedicated, and aligned team of experts. In practice, this comes down to deciding whether to keep your project internally, or get some help from the outside. Without sounding too biased, this choice largely depends on the composition of your team and how flexible they are.
A small multi-disciplinary team of experts can move faster because:
👉 An independent team isn't hindered by latency created by the many layers in a large organization.
👉 Keeping a team small means communication channels remain manageable, and collaborating is more intimate.
👉 Having a cross-functional team means having all the necessary skills to complete a project accessible within a single team.
Can you round up the right amount of people with all the necessary expertise? Can they dedicate themselves to the projects, say, 6 weeks at a time? Are they willing to adopt a way of working that’s possibly radically different than what they’re used to?
If the answer is no to one more or more of those questions, you might need a hand. As far as third parties go, you’ve got a wild variety of choices here. In general, if it's consulting you need, go with an agency. If it’s raw development power you need, go with a software development company.
If, however, you need someone that can do all of the above, that is drive an idea from its inception all the way to launch, then a digital product studio might be what you need.
Putting your users first
Before you even think of letting your imagination run wild and coming up with the craziest of ideas, you have to remember who you’re building this thing for. More importantly, do you even know who they are?
We’re treading into marketing territory a bit here, but if you don’t know your audience, creating something that’s valuable to them would be like winning the lottery. If you know who you’re targeting and you know what they’re struggling with, you’ll be miles ahead already without having even written a single letter of code.
That said, this doesn’t necessarily call for extensive market research either. You know, the kind that costs hundreds of thousands of dollars and takes two whole years to complete.
Remember, we’re trying to go fast here. Generally speaking, the two most important things you need to know about your audience are their buyer personas, and their respective buying journey. That’s enough to get you started. Because as we’ll see later on, you don’t need to take long before involving your customers with your project.
A final note on user-centricity, some of the best advice you can give to someone working on a project is this: try thinking in outcomes instead of features. What will your users be able to accomplish, or do better, after adding X or redesigning Y?
That way you kind of force yourself into the perspective of a user. It’s a great little “hack” to prevent people from becoming too self-indulged by their own ideas. The eyes of your team always have to be on the user. Because what good is a shorter lead time if you have to go back to the drawing board immediately after?
We always start our projects with a design sprint to ensure we're always building precisely what your users want and need. This four-day process begins with your challenges and ends with a customer-validated non-functioning prototype at the end of the week. Here's a day-by-day breakdown of our design sprint process; steal it to figure out exactly what to build in just four days. It also helps prove to stakeholders that their investment will pay off.
Working in agile development cycles
Now, on to the meat and potatoes of this article, and to many it probably won’t come as a surprise. The most straightforward way to drastically reduce the time to market of your digital product or service, is by going agile.
While many people usually link this methodology to start-ups, there’s definitely a case to be made for making even the biggest of companies work like a start-up again. We know this because we’ve done it.
We’ve helped big ticket telecommunications, FMCG, or pharmaceutical companies do a backflip and made them believe in taking an iterative approach to digital product development. Let’s break it down, shall we?
An iterative approach to digital product development
That iterative approach is the first big clue. In general, most companies use a waterfall or stage-gate process to organize product development. It’s a rigid methodology, and usually tries to fit the development of your product in its entirety into a single roadmap. Granted, this way of working looks really good on paper. Everything feels predictable; costs are accounted for, deadlines are set, expectations are clear. But one could ponder the question: does the end user give a shit about any of that?
Because the big thing that often gets overlooked, ironically enough, is the people you’re building this for. How will they feel about that app you’ve envisioned? Will they interact with it the way you intended? Sure, preliminary market research can offer some insight, but if, let’s say the UX of your mobile app is disastrous, you’re screwed regardless of how much value you put in there.
You don't want to end up spending hundreds of thousands or even millions on a digital product that nobody wants to use.
Creating a digital product or service that people love, is a complex recipe. And in today’s fast-moving marketplace, we’re facing unprecedented uncertainty. Why take that risk?
Here’s how things go down when you employ an agile process: instead of trying to tackle the design and development of a digital product or service in its entirety, you break it down into smaller pieces, or iterations.
Each iteration gets launched, or at least tested. Before you start rolling your eyes, yes of course launching a smaller-scale version of your product reduces the time to market. But there’s more to the story.
Let’s explore why you’d do such a thing in the first place. Regardless of what it would do to your lead time, fragmenting a big project into a non-fixed subset of iterations has one major benefit: validated learning.
Coined by Eric Ries, it’s a unit of progress that describes the things you’ve learned from trying out an initial idea, which you’ve measured against potential customers to validate its intended effect. In simple terms, you build something small but functional, let people try it, and gather feedback.
And here’s what this is really about: the feedback you’ve gathered at the end of each iteration, serves as input for the next. You learn and adjust as you go.
Going agile is really about taking a pragmatic, evidence-based approach to product development. It makes sure you’re building the right thing for your users. Or at least warns you early on when things aren’t working out. A leap of faith is best taken in small steps, should you wish to stick the landing.
If you're curious about what this looks like in practice, you should check out this case study about how we took Edgard & Cooper through multiple iterations. This one increased online revenue by 44%, retention rate by 38%, and a 9.6% increase in average order size.
How big or small should an iteration be?
That ultimately begs the question, what’s an iteration supposed to look like? Each development cycle should ultimately yield what’s called a Minimum Viable Product, or MVP for short.
Once again quoting Eric Ries, it’s a smaller version of your product that allows your team to collect the maximum amount of validated learning. Now what exactly should you be validating then? Well, with any new product, there is a set of what you’d call leap-of-faith assumptions that surround it. Leap-of-faith assumptions are those kinds of assumptions that you take for granted.
You don’t know if they’re right or wrong, you just go with them. For example, when iTunes and the iPod were coming up, Apple just assumed people would want to pay for music through their platform.
Whenever you’re tackling a project in an agile fashion, you start off by listing out these assumptions. You then build your MVP in such a way that the feedback you get, validates one or more of those assumptions. We use the MVP scorecard shown below to map out these assumptions and plan our MVP roadmap.
An MVP provides you with an understanding of what people actually want, not what you think they want. With that kind of knowledge in your back pocket, you can rest assured you won’t ever be needing to undo months or even years of work. That is perhaps the biggest time-saver of all.
Using the right tools for the job
One thing about technology is that it doesn’t evolve backwards. Things continuously become easier and more convenient to use. Hence, people can do stuff faster. And this also is reflected in the kind of tools designers and developers use.
Even better, occupations with a steep learning curve, like programming, database management, web design etc., have now become a lot more accessible to non-technical folks thanks to the insurgence of low-code or even no-code tools. Essentially, these tools hide the raw, ugly code and replace it with a user-friendly interface.
Let’s explore some of our favorite tools, ones that rhyme very well with an agile way of working.
Don’t even think of making a spreadsheet when trying to organize and structure your work.
Basically, Jira is a piece of project management software. It works particularly well for teams who practice agile methodologies, as it provides scrum and kanban boards out-of-the box. You can create boards that work like a kind of task management hub, providing all the transparency you need on a team level.
With the way everyone’s work is structured and fragmented, everybody knows exactly what he or she is supposed to do, and what their efforts will be contributing towards. Instead of planning a dozen meetings to get everyone on the same page, a daily, 15-minute stand-up is all you need. We even give our own clients access to these boards, so they can see exactly what we’re doing, and when we’re doing it.
Arguably the best collaborative, cloud-based design tool out there. We use it for designing web pages, user interfaces, and for prototyping purposes as well. The two greatest things about it are the ability to create component-based design systems, and to rapidly test user flows without any actual front end development. The former refers to creating a ton of reusable UI assets you can easily modify and piece together to create something new. The latter is about stitching together, say, a series of screens of a mobile app, which Figma can then present to users like it’s a real, functioning app. Perfect for user testing!
The ultimate no-code platform for web design and development. It essentially makes web design as visual as can be. You wouldn’t even have to look at a single HTML tag if you wanted. We use it for designing responsive websites, landing pages, ecommerce sites… You name it. Beyond that, it also bolsters a pretty flexible CMS (Content Management System), and it's also a hosting platform. It’s got a lot of features that would otherwise require a ton of custom code already baked in. With a bit of practice you can turn the design of an entire website into a functional website in a matter of days.
It's the Excel you wish you had. It’s not just a spreadsheet editor, it also doubles as a database. It can store information in a spreadsheet that's visually appealing and easy-to-use, but it's also powerful enough to act as a database that businesses can use for customer-relationship management (CRM), task management, project planning, and inventory tracking. We use it all the time as a kind of surrogate back end that’s incredibly easy to set up. Especially when your goal is to learn quickly by experimenting, the last thing you want to be doing is wasting weeks trying to get your little experiment to play nice with your existing back end.
Our analytics tool of choice, especially when it comes to mobile apps. Mixpanel is an event-centric platform where tracking is based on events. We use Mixpanel to track events, discern trends, and gather targeted feedback. Mixpanel is more targeted than Google Analytics and the data they provide offers lots of possibilities. It’s undoubtedly one of the most advanced tools when it comes to analyzing how your users interact with your product, and why they take certain actions.
The grass is always greener, right? And if agile were perfect, everyone and their mother would probably swear by it. That’s clearly not the case. A lot of things need to go right for it to flourish.
A lot of it has to do with how closely your team can adhere to the process, how well they can collaborate.
This can be tough to maintain. For manager or C-level types, the lack of clarity long-term can be a turn-off as well. Because who knows where the project will be headed after five or so MVPs. However, in our experience it’s still the way to go if you want to make sure you’re building something people will actually end up using.
Long story short, if you can wrap your head around the idea of validated learning, and you can get your hands on a team that lives and breathes agile, you might want to give it the benefit of the doubt. Remember, whoever learns fastest, wins.
If you want to read an in depth case study of how we sued this philosophy to go from prototype to launched app in 4 weeks, you can find it here.