The speed at which the economic landscape shifts has been increasing since the industrial revolution and the emergence of consumer technology. Never before has the customer been empowered with so many choices and information about those choices. Customers are savvy, informed, and ready to jump ship if a better product or service comes along. In a free market, successful companies that become complacent or comfortable with their share of the market, who don’t carefully consider the needs of the customer, become less competitive over time.
There are three pillars of success in a modern company, and defining each requires the redefinition of the others. They are not questions that can be answered once, or in a vacuum independent of the others. The construction and reconstruction of these pillars must be done continuously, in tandem, and requires effective dialog between all stakeholders in an organization. The three defining questions for any modern business are:
- How can we deliver more value to the customer?
- How can we be more profitable?
- From the point of view of technology, manufacturing, and/or the ability to deliver a service, what is possible?
Placing too much emphasis on using the latest technology without doing sufficient customer research is a great way to build something fantastic that nobody wants. Being overly obsessed with pleasing your customers and not having a plan to make a profit is not sustainable, and will eventually cripple your business.
On the other hand, capitalizing on a company’s current position to appease shareholders or investors, without innovating, improving, or optimizing, might be profitable in the short term, but in the long run you will likely lose market share. From observing the attributes of long lasting businesses, it seems that the most important pillar in any business is providing value to its customers. But without a healthy structure in the other two pillars, the foundation of a company will be out of balance and its trajectory unpredictable.
Once you decide that, as an organization, you want to deliver the most value to customers while balancing your business priorities and what is technically possible, the question is how? How do you define those pillars for your company and turn the metaphorical into the physical, and actually construct them?
Well it turns out that people have been trying to balance these three pillars since the earliest forms of commerce. As a trader of spices in 500BC, you most definitely had to consider customer expectations, profit margins, and the emergence of new techniques for preserving your product. What has changed in the marketplace is the rate at which the pillars must be redefined. There has never been a greater rate of change for customer expectations, the landscape of the market, and what is technically possible.
So let’s dive into some old and new methodologies that companies use to implement, develop and balance the three pillars. I’ll review four methodologies: waterfall, Lean, design, and Agile. Each methodology has strengths and weaknesses, and since implementations can vary widely, it’s useful to understand how and when to apply elements of each.
Waterfall breaks a project down into clear, predefined phases. The phases follow a linear path and each step relies on the success of the previous one. Customer demands, business priorities, and the capability of current technology are all researched and documented before the commencement of the project. There is a huge amount of planning and preparation done prior to starting development, and this is the main difference between waterfall and other methodologies. Due to the level of preparation, waterfall offers a high degree of confidence and certainty that the resulting product or service will address the customer’s expectations, be profitable or helpful for the business in some capacity, and make use of the most advanced technology that is accessible and affordable. When the project starts, companies following waterfall assume they have accounted for all potentials for failure and have put contingencies in place.
The most valuable benefits of the waterfall method are only present if the initial assumptions were correct and the development of the product or service goes mostly as planned, with little to no change in customer habits, economic landscape, or related technology during the creation or launch period. Due to the level of planning and documentation, it can be relatively easy for new team members, investors, and other stakeholders to get up to speed. The outcome of a project is well defined, so there are few surprises in what the team delivers. All or most of the resources required to complete the project are either purchased or accounted for during the planning phases, leaving little room for financial woes. Assuming that the project requirements don’t change, the human talent that will be needed is also known ahead of time, equipping human resources with more time to hire.
Customers, the economy, and technology are all rapidly changing, so using waterfall for projects that span multiple years can have some negative effects. Since so much effort went into planning each stage of the project, with every step relying heavily on the step before, flexibility is not inherently present. Pivoting just slightly might have massive repercussions further down the line.
For example, maybe an assumption was made about the abilities of a specific technology, and it turned out to be either incorrect or more difficult to implement than expected. Spending more time on the implementation could affect the delivery timeline and choosing a different technology might impact future dependencies. As a result, projects may go over budget or fail to be delivered on time due to unforeseen internal or environmental factors.
Customers are often not involved after the initial planning phases and typically don’t have the opportunity to try the product or service until it is completed. As a result, when the product is finally released, it might fail to meet customer expectations, be difficult to use or consume, or not deliver as much value as originally anticipated. Having said that, waterfall can be great for projects or organizations who anticipate little change to market conditions, customers’ expectations, the team or technology’s capabilities, and the business priorities. In today’s climate, however, one can expect substantial change in one or more of these areas during the development of a product, so the waterfall approach is becoming less effective at consistently delivering value to customers.
Lean, or Lean Startup, is a concept from the world of manufacturing; the term was coined by an MIT professor who was describing the system that Toyota manufacturers in Japan were using – Kaizen. Lean describes an organizational system that intends to provide maximum value to the customer, while eliminating wasteful practices and procedures. Relating to digital product management, the poster child of the Lean methodology is the minimum viable product, or MVP. It says that the development of every new product, service or product feature is an experiment to be learned from.
Every MVP should yield two lessons: should this continue to be built and, if so, can we create a business around it? Work shall be performed in short cycles and should only continue if the lessons from the previous cycle permit us to do so. When deciding how to prioritize work, Lean asks, what is the least amount of work needed to answer the most critical questions about our product, service, or feature? This approach reduces the financial and resource allocation risks associated with developing new ideas, and promotes experimentation within teams and organizations.
It can however, be difficult to implement Lean thinking in an organization. With teams placing a high emphasis on velocity, often including output-based bonuses rather than being outcome-driven, experimentation can be frowned upon. Often, MVPs are used merely as a phase 1 for a product or service, and sufficient time and resources are not allocated for learning from the experiment, thus missing a critical step in the Build-Measure-Learn loop encouraged by Lean. And since the team has committed to a project roadmap, it is not clear what to do if the MVP indicates there might be issues in meeting customer expectations or business priorities, and whether the team should pivot or persevere. If a highly experimental MVP does show potential, companies might not have a clear path for the innovative solution to be integrated into the official line of products or services. Sometimes innovative teams working on an MVP are working in a vacuum, separated from the company’s core business objectives, which can result in technical or strategic conflict or misdirection.
The concepts of design thinking were first introduced to the world in The Sciences of The Artificial, a 1968 book by Nobel Laureate Herbert A. Simon. The methodology attempts to solve problems by breaking down our predefined notions of how something ‘should be’, and putting ourselves in the shoes of the customer or end user. Core concepts from the social sciences are utilized and applied to the development of products and services that solve problems or address some need for people. Who are our customers and what are the problems that they face? What drives their behaviour and what are their emotions, needs and motivations? After we’ve identified our customer, design thinking encourages observing them while using the product and taking note of their habits. Are they using the product in a way that was not foreseen? Are they struggling with some functionality? Do they even realize a certain feature exists?
Design thinking is an approach to running a business that emphasizes creating solutions that address the customer’s fundamental needs, but that also satisfy business objectives and are technically or physically possible. The strategy was primarily used by designers who were creating user interfaces and product designs, but its core principles are now widely used agnostic of profession. Like other modern methodologies, design thinking encourages working in short iterations, but emphasizes delivering more value to the customer as a constant and recurring theme.
With a customer-centric approach, empathy for end users is garnered and can lead to great, incremental product improvements and discovery. Sometimes though, the position of user advocacy is left to front-end or product designers, and the customer’s fundamental needs are not deeply understood company wide. If a cross-functional team does manage to schedule time for a customer-centric brainstorming session, the result is often a mess of whiteboard notes and sticky notes, leaving groups feeling like time was wasted.
Performing real research with actual users is fundamental to this process. Design thinking implies continuous thought and evaluation of the customer’s needs, but if done poorly or when there isn’t a clear path for implementation, the team may start to focus on the amount of output as opposed to the amount of value delivered to the customer. On another note, teams throughout the company might have different understandings of the customer’s needs, and so effective communication between teams is essential in determining how to provide value to the customer. For example, your customer service team might define what is valuable to the customer differently than the engineers.
It is also important to point out that while user feedback is essential to creating a great product that users love, you must have widespread aggregate feedback from many different users across many different demographics. Be wary of falling into the trap of taking the feedback of only a handful of users and building a plan against that, as that could lead to costly pitfalls as the majority of the audience may not find value in the changes recommended by a few.
The term Agile was officially coined in 2001 as a result of a document called Manifesto for Agile Software Development. The entire manifesto can be found at
The core tenets of Agile make a few things pretty clear. In an Agile company, the employees and the efficiency and effectiveness of their communication are more important than following stringent company policies and the chain of command. Having a product or service that is of high quality and does what it promises, is more important than documenting and selling one that is of low quality and has many flaws. Building products with customers is better than building products for customers. The ability of an organization to respond to changes in the environment is of higher value than the ability of its employees to adhere to a plan.
In order to accomplish these goals, Agile encourages iterative cycles of development of a product or service. Plan, do, and reflect, every two to three weeks, or a period that makes sense for your company. Each work period should result in a small, encapsulated new addition to a product or service, allowing the team to gauge and reflect on whether the effects met customer needs and accomplished business goals.
The reflecting is the most important part of this process, as that is where a team can take into consideration customer feedback, technical possibilities, and/or changes in the economic landscape. After releasing a new or updated feature, what do customers think and how can we measure that? Did we find out that something is technically easier or harder than we originally anticipated? Are we headed in a direction that supports our business objectives? After the reflection, the team or product managers can either decide to adapt, or continue in the same direction.
Agile is great for teams developing a product or service that has some degree of uncertainty in customer expectations, market conditions, or complexity of development. Agile was made for the age of change and uncertainty, which is why it is so popular. But as with any methodology for running an organization, it has its flaws, many of which are due to poor implementation.
Since Agile is often considered a team level strategy, implementation at scale or across a large organization can be difficult. Teams implement optimizations locally and often don’t consider or are ignorant to the goals of other teams or the company as a whole. Furthermore, how the optimization of one team affects other teams is often unknown and not accounted for. An effort to reduce waste in one team, might be creating work for another, or the effort could be duplicated.
In an attempt to reduce the chaos that inevitably ensues from potentially hundreds of self organising teams, multiple strategies have been developed to help implement Agile at the organization level. Scaled Agile Framework (SAFe) is one such strategy that seeks to unify multiple Agile teams into one team, called an Agile Release Train (ART). These teams of teams work in cycles called program increments that typically last five of the individual teams’ cycles. The work process of the program increment is very similar to how an Agile team operates.
The united cross-functional team of teams plans how to deliver value to the customer during the next increment, while determining and delegating dependencies. At the end of the program increment, there is a retrospective held, and similar adaptive practices take place. If the size or complexity of a project is too much for one ART, which is usually around 150 people, another layer of Agile abstraction is added, called a Solution Train. A solution train manages multiple ARTs and through its own implementation of Agile, oversees the development and release of a large project. You can read more in our Modus blog, Scaled Agile – Why? When? How?.
So what methodology or combination of methodologies is right for your organization? There are many unique attributes to a business, including the implementation of a methodology, the customer base, the landscape of the underlying marketplace, the relevant technology, and most importantly, the people on your teams. The sum of your employees is what ultimately defines your company, so implementing different processes should be done experimentally in an effort to tease out the best collaborative work and deliver the most value. The goal should not be to strictly adhere to one methodology because your organization has committed to it, but rather to examine why your business exists in the first place, and tailor your solution appropriately. The business exists, or should exist, to deliver value to customers, first and foremost.
Following Agile practices can help teams and organisations as a whole deliver small chunks of work in regular intervals. Maintaining short work cycles keeps teams nimble and equips them with the agility to make frequent pivots based on internal or environmental feedback.
Design thinking allows teams to empathize with the customer and steers the ship towards delivering user value. It puts each and every employee in a position to think about how their work affects the customer, and how they can deliver more valuable outcomes. Using the minimum viable product (MVP) strategy from Lean Startup empowers teams to test hypotheses about customers, technology, or the market, while keeping the initial investment low.
Focus on delivering value to your customers over following an existing process or methodology, and the result will be your own methods for success. In order to help our clients launch successful technical projects, Product Kickstart was created. Our engineering and Atlassian experts apply Lean and Design thinking principles and help our clients with the adoption of Agile best practices through coaching and optimization of project tools.
- What the Heck is Product Ops? (And...Do We Need It?)
Product Ops can streamline your business processes and accelerate your Product Management team. In his…
- Which Jira Product is Best for You?
Atlassian’s recent acquisition of AgileCraft added a new product, Jira Align, to the Jira Arsenal.…