At MOHARA we build products based on an agile mindset – in uncertain environments, this helps us produce supernormal results. When we start working with founders and heads of innovation, they are often confused by the terms agile, scrum and product.
This is unsurprising – in the field of product development terms are wielded carelessly and the result is often confusion.
This article is designed to help you better understand what these terms mean and how at MOHARA we focus on an agile mindset.
Here are some terms we need to understand:
- Agile development: A software development methodology based on iterative development, requirements and solutions that evolve during a product build.
- Scrum methodology: A type of agile development methodology that promotes breaking work into manageable chunks (sprints) and then tracking progress and re-planning every day in short meetings (stand-ups).
- Waterfall development: A software development method that, rather than being agile, is more sequential. When one phase is complete the next phase starts with far less scope for iteration or re-evaluation.
- Agile mindset: This goes beyond development and imbues in the whole organisation a way of thinking that focuses on outcomes. Primarily taking the user from where they are now to where they want to be in the future.
- Product ownership: A product owner is responsible for ensuring that a product meets user requirements, delivers outcomes and is delivered using the allotted resources.
Often the terms ‘agile’, ‘product’ and ‘scrum’ are conflated when they relate to very different aspects of the product development process.
Many product managers claim to deploy AGILE principles to manage the process of bringing a product to market.
For this to become meaningful, it needs further unpacking.
The term ‘agile’ can be used to describe a development philosophy (layer two above) and an organisational mindset (layer one above).
Agile development refers to a flexible development process that considers new information to iterate. An agile mindset goes way beyond the build of the project and asks fundamental questions on how the product sits within a business and whether the approach is correct. It looks to remove risks by testing assumptions about the product before getting an engineering team started; this article on Hackernoon gives some more context on the idea of de-risking product development.”
The Road to Nowhere
Let me give an example, originally covered in Forbes magazine.
Zara is a good example of a business that uses an agile mindset to great effect.
The fashion industry is notoriously fickle. Something that is popular one season may quickly lose favour with consumers. With changing trends, celebrity endorsements and weather all factors in the popularity of a product, Zara needs to react quickly to changing circumstances.
It needs an agile mindset to take the user from where they are now (wanting a new Autumn coat from Zara suitable for the unseasonably warm weather but still in Burgundy) to where they want to be (wearing the aforementioned coat).
It all sounds simple but requires an agile mindset.
Zara needs to first be tuned in to what the customers want, and then have the infrastructure to deliver changes quickly. To achieve this, Zara uses nearshore production, making most product lines in local countries Spain, Portugal, Turkey and Morocco – thus enabling emerging and changing customer demand to be met.
This is different to agile development because Zara is placing the customer at the centre, asking: what does my customer want? The infrastructure is then set up to deliver this as quickly and efficiently as possible.
The Role of the Product Owner
The role of a product owner can cover all or some of the parts of the pyramid. In most businesses, the product owner focuses on the development philosophy (two) and tactics layer (three); they aren’t working on instilling a team mindset. At MOHARA it’s different.
The MOHARA approach – Does the Product Make Business Sense?
We ensure that product ownership covers all three layers:
- Mindset
- Development Philosophy
- Tactics
As a partner in product ownership, our job is to de-risk the development of your product and subsequently your whole business proposition as quickly and simply as possible. This involves asking fundamental questions and starts by unpicking the key assumptions and making sure the business case makes sense.
We always look at unit economics:
- Is customer lifetime value greater than the cost to acquire + cost to serve + R&D costs?
It’s surprising how many businesses haven’t crunched the numbers pre-development; this is a critical piece of work that helps validate the product build.
We’ll also counsel businesses to look at competitors and alternatives to be clear on where the product fits into the market and what value it adds.”
Once we’re comfortable with some of these more existential questions, we can start the development process
Everything has to go back through the lens of:
- Does this make business sense?
We’re entrepreneurs ourselves – we’ve walked this path many times and we’re obsessed with using resources efficiently. We only start writing code once we’ve removed as much risk as possible.
Agile development is a useful concept, but we prefer to look at the whole puzzle. Our mindset is to only start building products once we’ve validated assumptions about the direction we’re taking.
This agile mindset allows us to address the key issues and change direction when necessary to make sure the end product is a winner for users and the business.
