Building software products has never been an easy task, but the challenges we face in 2021 are different from the ones developers encountered two decades ago. The beginning of 2001 saw the dawn of the “agile era” in software development with the publication of the agile manifesto. It was an important shift in how software development was approached.
Now new challenges lie ahead and we see that another shift is happening right now, allowing us to continue building better software products faster. A number of new approaches to software delivery drive the change, like DevOps, SRE, Continuous Integration/Delivery, or Lean. It’s worth taking a look at the currently available tools and environments for software development and inspect whether they allow us to go beyond the Agile Manifesto and truly ask ourselves, how great software products are made.
Old habits die hard
Although it has been 20 years since the agile manifesto was published, many businesses still fail to take it to heart. They want to build software products with the waterfall approach, where the roadmap and functionality list is more important than actual feedback provided by both users and customers.
They insist on using tools they are familiar with rather than experiment with something new, which could make the software product better. They have a plan and they wish to follow it to the T, with no consideration for what their users actually want. Very frequently, they will ask for the users’ opinion only after releasing a feature, or even worse – the product.
What are the results of this approach? Many times, the development costs pile up before the product is even first released, and upon release, it turns out that half the functionalities developed are not needed and have no value for users. It’s a waste of time and money and although it does not always spell disaster for the business, it is certainly a major setback.
Building software products has never been an easy task, but the challenges we face in 2021 are different from the ones developers encountered two decades ago. The beginning of 2001 saw the dawn of the “agile era” in software development with the publication of the agile manifesto. It was an important shift in how software development was approached.
The Agile Manifesto preaches close collaboration with stakeholders. Back in the day, the tools for communication were limited. Currently, development teams can easily reach out to users asking for feedback, allowing them to address issues and better understand what can be improved. It’s not common to encourage software developers to talk to users, but it’s one of the most powerful ways to make them understand real problems and gain a different perspective on their work.
We encourage a high level of transparency of business objectives to let teams understand what matters. When teams understand business objectives they can use tools to experiment on live products. Rapid experimentation allows you to lower the risk of failure and increase the probability of reaching business goals. You can use Experiment Canvas to align team members on what is the riskiest assumption test and allow them to collaborate.
It doesn't make sense to hire smart people and then tell them what to do; we hire smart people so they can tell us what to do. Let them know what is important (like Business Metrics, KPIs) and let them set assumptions and features for themselves. Developers are smart creatures, you should allow them to act. Business owner's responsibility is to create a culture of personal autonomy, competence and relatedness and make all people understand well what problems we solve for users.
Great outcomes, not output
Many organizations build roadmaps or ask their teams for estimations. Their teams are focused on what is the output of each sprint, not the impact that it will have on the business. A book called Inspired (which we recommend) convincingly explains why roadmaps are uninspiring and ineffective for creating great products.
Many teams struggle with delivering value to customers. This is often the result of not measuring the outcomes of their work in each iteration. They deliver features that don’t have an impact, hoping that somebody uses them. That’s why instead of using traditional roadmaps with a list of features – use Outcome-Based Roadmaps. It’s just a tool, but it makes communication between business and software teams more effective.
Teams should be measured by the outcomes of their work, not just output. It really doesn’t matter how many sprints they complete, or how many points they deliver every week. Teams need to understand what is important for the product to achieve success, be aligned with that and work towards it. Ultimately, actual results are: happy customers, increased sales, bigger user base, number of transactions, etc..
We are often asked for an estimation or a roadmap. Well, an estimate can help you in your decision-making and planning process, but it should be seen as a suggestion, not a commitment. Let teams create proof of concept before they commit to an estimate – it will be far more probable.
The continuous path towards a great software product
The poet John Heywood famously said that “Rome wasn’t built in a day”... Well, neither was Facebook, Etoro, Uber or any other great software product whose success everyone wants to emulate.
It’s good to have a vision for what you want your product to become, but if you start off with a list of features that’s 20-pages of miniscule print, you’re already setting yourself up for failure. A tool such as an estimate becomes virtually useless, because it is impossible to estimate work so far ahead into the future: there are too many steps to take along the way.
Building software products that enchant millions of users doesn’t involve developing as many features as you can in the shortest amount of time possible. You start by identifying a core problem you want your product to solve and build the functionalities that address that specific problem. And development doesn’t stop once this product is built. Once you have a version of your product that does what you wanted it to do, you release it and check whether your users use it for the purpose it was designed for and you listen in on what they have to say about what they need next. When a team delivers a feature to production, their work isn’t finished. Create a space for them to iterate on it. Usually, the first idea is not the one that generates the most value.
The poet John Heywood famously said that “Rome wasn’t built in a day”... Well, neither was Facebook, Etoro, Uber or any other great software product whose success everyone wants to emulate.
As your user-base grows, so should your product development team, as you will need to continue responding to more and more user requests and you’ll need to address issues within the product that will inevitably come up, regardless of how brilliant your development team is.
Rome was not built in a day, but they were laying bricks every day. And in software development you need to pay constant attention not only to what the next brick is going to be, but who you’re laying it for.
Making mistakes is part of the process
You might follow all the guidelines there are. You can read every book on software development and product development and follow all the advice that is out there and still, you’ll make mistakes. You’ll release a feature and find out that it doesn’t address the problem you wanted to solve. This is not the moment to break down and give up – it’s all part of the process.
Take each failure and learn from it, bearing in mind that if you’re not making mistakes and you’re not failing, that means you’re playing it safe and you’re not really innovating, but regurgitating tried and old ideas. That will not do in the long-run. If you’re not challenging the status quo, then there is probably someone out there already doing the same thing better than you. The only way you can make a real difference is if you do something that’s never been done before, but that always comes with a risk. As a leader you need to create space for your software teams to make mistakes and analyse them, rather than jump to developing another feature immediately after finishing the previous one.
Teams should be encouraged to deliver frequently to production (ideally a few times per day). You should include Continuous Delivery methodologies to your deployment pipeline. That means that each commit to the repository should go to production as quickly as possible. Thanks to automated tests and proper monitoring you shouldn’t be afraid of shipping software. You will make mistakes, but what truly matters is the recovery time. When you ship small, you can quickly revoke the change and draw conclusions from the mistake.
Many companies employ testers to do the quality check of the software when it’s about to be delivered to production. In our opinion it’s a mistake, testers should be included in the development process, so they can see how to best ensure quality. They can notice places that require additional automated tests, and can work on tools that verify golden paths in the application. What is important here is making them think in the long run as complexity of the application grows.
Making mistakes is inevitable, you should focus on making sure they will be small and easy to recover from. That will allow you to move fast and correct the development direction easily.
Conclusions
The ever-increasing popularity of software products means the challenges we face today are no longer simply matters of technological limitations or incorrect mentality. Those problems haven’t all gone away, but the biggest challenge businesses face today is in understanding that if they want to make it in this highly competitive world, they have to embrace the unknown, and take a leap of faith, trusting their development teams with more than just creating code.
Business leaders need to trust that if they give developers access to knowledge of business goals and the challenges users face, they will come up with revolutionary applications to the technologies they work with and build an incredible product.
Visionaries have to let go of the need to control the entire process and instead, allow the process to guide them and trust their teams to make the right decisions for the product. As long as the focus is placed on the end-user – the business will come out on top.
