Agile Product Development for startups and enterprise companies

Agile Product Development for startups and enterprise companies.

In this article, we are going to talk about Agile Development and its advantages and disadvantages in comparison to a Waterfall approach. We will give you enough insight to help you decide on the best plan for your next big digital product.

Before getting started, we feel it is important to give you a quick overview of our history and expertise as a company.

RebelDot started as a tech subsidiary of a large product company in Washington, the USA, in 2008. For a few solid years, we worked on building digital products for large & renowned insurance companies, as well as Fortune 500 companies. We spent four years perfecting and solidifying our approach to building digital products. Later in 2012, we decided that we wanted to use our product knowledge and experience in helping companies, startups and enterprise, accelerate their way towards digitalization and technology innovation. Fast forward today, our cross-functional teams have helped more than 50 companies bring digital products to the market.

Today, we are lucky enough to have experienced a lot of different scenarios and approaches when it comes to building products. Our interactions with various companies & business scenarios have once and for all showed us the importance of being Agile when it comes to both startups and enterprise companies.

What is Agile Development?

Before getting any further with Agile Development, let us take a look at the meaning of it.

AGILE = the ability to create and respond to change. A way of dealing and succeeding in a fairly turbulent environment; the ability to adapt.

It is our understanding that the authors of the Agile Manifesto went for Agile as a label for this idea because the word represents adaptiveness, which is so important to the entire approach.

Translating this entire concept of agility into the product development world, we see how being Agile means adopting an iterative approach to product management and software development, helping teams deliver value for customers at a fast pace.

So instead of big reveals and big bang launches, an agile team develops in small iterations. Product roadmaps, requirements & features are evaluated continuously, creating a natural mechanism for quick response to change. Pretty cool, huh?

Customer feedback is extremely important in building digital products following an Agile approach, and both testing and development are done based on customer feedback and response.

Agile & Waterfall — which one should you choose for your digital product?

While Waterfall is a linear model for software development, Agile is an incremental and iterative approach to building software. Although with more recent history, Agile development has gained a lot of popularity, especially in the technology startups scene, where openness to change and adaptability to market demands is vital.

Below are a few of the most important points you should take into consideration when having to choose between Agile and Waterfall for new product development.

Taking a quick look at the history of Agile Development, this new methodology came to solve some of the most evident problems and challenges product teams faced when following a Waterfall approach.

Customer feedback & being open to change.

Planning to launch new digital products in today’s ultra-competitive technology scene, needs to come with an extraordinary ability to adapt to change and customer feedback. If you have been following us for a while, you know we place great emphasis on customer feedback for an important reason: it helps stakeholders make sure that what they build responds to real customer needs. By encouraging incremental development, agile development provides a framework for avoiding big product reveals after immersing in months, maybe years of development.

Agile development helps stakeholders prioritize the features that they want to include in their product, by encouraging product teams to think about the challenges and the problems the digital product is solving for the market they are launching on.

While a Waterfall approach places great emphasis on extensive planning before immersing into development, being Agile might mean you are not 100% sure of how the digital product might end up looking. Still, you are sure that what you build is what your customers want

Does being Agile mean less financial predictability?

Short answer, yes. Still, you will be surprised to find out how less budget predictability might work to your advantage. Here’s why:

You have a great product idea, that is (we hope) based on a problem you have identified, and you wish to solve for your customers. For the sake of this story, let’s assume that you are planning on building a platform that aims to connect artists with art collectors with the scope of purchasing art pieces. The main and first to be developed features of your digital platform will be centred around solving this exact problem: creating a way for art collectors to connect with artists. Now, you might have an idea of other interesting features that might suit the purpose of your app, but you can’t know for sure if these features add value to the entire experience of your users. Following an Agile methodology, you will release the first version of your digital product or an MVP, collect feedback from the way users interact with the applications, and only then decide on which features will go into the second version of your digital product.

Since there is no full visibility over the entire product roadmap, development teams will find out it is almost impossible to accurately estimate the entire development effort of your app. Instead, they will create a ballpark estimation, highlight the minimum effort for developing your app as well as the maximum amount of effort, with the mention that if the scope of the application changes, the estimates will end up being changed as well.

Let’s think of the same business scenario, following a Waterfall methodology for product development. We would look at all features imagined for this specific digital platform and estimate everything with greater accuracy.

The risk? Since in the case of Waterfall product development, customer feedback is deferred until very late in the project, you might fall into the (very dangerous) trap of building a product that your customer base doesn’t need. It’s because you build on assumptions and not on real feedback, as in the case of Agile Development. So, you end up having a clear overview of the entire development effort that might end up being pointless once you realize your customer base needs something else. Getting into changing the whole system is like jumping into a pitfall.

Time to market.

Time to market

If you wish to place a product on the market as soon as possible, then, without any doubts, Agile Development is the way to go. Encouraging feedback based iterations and incremental development, and Agile Development team will advise fast releases, followed by rapid improvements.

In the case of the Waterfall Methodology, you might have to wait for months and years to have your product on the market.

User Learning Curve.

Although there’s not that much discussion around this topic, our years of conducting development for companies have shown us another important, user-centric aspect when it comes to Agile product development: fast, and incremental releases help users adapt to the behaviour of your mobile or web application on the go. You want to first launch a product with fewer features, slowly upgrading the experience to ensure a short learning curve for your users. The more seamless and minimal the first version of your product is the higher the adoption and usage rate.

To better illustrate this, let’s take a look at Facebook and the eight main features of the first version of the app — released in 2004:

According to Adam D’Angelo & Business Insider, they are:

  1.  User accounts (with real names required), restricted to @harvard.edu email addresses;
  2.  Friends, including friend requests;
  3.  Invitations (no contact importer; you had to enter each email address individually);
  4.  Profiles, with a single photo for each user;
  5. Ability to list user metadata like gender, birthday, dorm, phone number, favourite music, favourite books, “about me,” courses (structured);
  6.  Search by name, class year, courses, other metadata;
  7.  Some privacy restrictions to limit who could see your profile (friends only, only people in my class year);
  8.  A feature to visualize a user’s friend graph, which was later cut.

Today, Facebook is a sea of complex functionality that takes a lot of time and energy to learn, and reaching this level of complexity required a lot of user feedback and analyses that are still undergoing.

Placing an over-complex, feature-crowded product on the market with giving your users time to adjust to lear your platform will eventually kill your user base.

To build or not to build an MVP.

Time to launch

As an  Agile Development team, we encourage startups as well as enterprise companies to first build a minimum viable product (MVP). 

Being Agile will help you identify the problems you wish to solve for your customers, before identifying the features. 

We know how tempting it is to talk about the killer features and functionalities of your new product but make sure not to hurry into this. We’ve seen a lot of entrepreneurs who just want to go out and build a bunch of things without a clear objective, and that’s just money thrown out on the window.

Nonetheless, an MVP is a huge part of being Agile. We covered everything you should know about building an MVP in this article about how to innovate with minimum viable products and rapid customer feedback

We hope this article gave you a good overview of what it means to build digital products — the Agile way. If you feel like there are some aspects we did not cover,  reach out and we’ll be happy to spend time in conversation with you.