Requirements are untested hypotheses about customer needs

In agile our highest priority is to satisfy the customer through early and continuous delivery of valuable products and services. We achieve this through rapid build, measure, learn cycles.

Research shows that 80% of features are rarely if ever used. Managers don’t know what customers want so they put in everything they think customers might want. This means that business requirements are untested hypotheses about customer needs.

Screen Shot 2018-12-20 at 1.45.01 PM

In agile we believe that simplicity is essential. If you can focus on what customers really want you can cut project time and cost by 80%. To achieve this you need to test your requirements and design concepts early and often.

No alt text provided for this imageThis is why you should be deploying to production every sprint. If you cant deploy a feature then watch how customers are using your product, show them a design concept or prototype and find out what they think.

For more information see our courses and consulting at IE Digital – Silicon Block.


Product Owner v Product Manager – what’s the difference?

Managing the development of new products and product features is a complex process, with multiple stakeholders and competing priorities. Often, in large teams, the role of product lead is split between Product Manager and Product Owner.

The roles can overlap, but the main difference is that the Product Manager is focused on product / market fit while the Product Owner is focused on getting the development team to build valuable product features.

Product Manager

The Product Manager is responsible for ensuring that the organisation develops and delivers a profitable product that meets the needs of the market. The Product Manager develops a product vision with customers and stakeholders and turns it into a prioritised, high level roadmap of activities that maximise business value. The product roadmap may include a mix of customer research, sales, marketing, feature development, training and process improvement activities.

Product Managers have a broad scope which means that they may not be able to give the development team the time and attention they need. In this case they may appoint a Product Owner to work full time with the Development team on their behalf. If they do this they should meet with the Product Owner every few days and attend the planning and review session with the development team every couple of weeks to ensure that the development team is prioritising business value correctly.

Product Owner

Product Owner is a role that was popularised by Scrum, an agile framework that helps you to develop valuable products in half the time. The Product Owner is the interface between business stakeholders, customers and the delivery team. Their primary goal is to maximize the value of the work done by the development team.

Product Owner is a full time job that requires skill in product management, business analysis, communication and project management. Located alongside the development team day to day, the Product Owner works closely with stakeholders to define the objectives, understand user needs and work out what features are required to improve the user experience and meet business objectives.

At the same time they work closely with the development team to rank the product features by business value, risk and dependency and analyse, design, develop and test the features in an incremental cycle, showing stakeholders what they have developed every few weeks.


The Product Owner is the critical role in an agile development team. A good Product Owner is customer focused, passionate, empowering, honest, analytical, detail oriented, decisive, available and engaged. It’s a fascinating role for a Product Manager, Business Analyst or Project Manager that provides considerable career growth for people lucky enough to do it.

Learn more about our agile courses.

5 ways to be an effective Product Owner

A Product Owner has the most important role in an agile team. Their job is to maximise business value by communicating the product vision, prioritising the product backlog and taking key stakeholders on the journey. Here are five tips to help you be a better Product Owner:

1. Advocate for the product

The Product Owner should be the champion for the product. They should know the product vision and details inside out so that they can communicate it to stakeholders and the team throughout the project and they should make sure that the team get the resources and information they need to maximise business value. The role of the Product Owner can be intense, as they’re pulled in many directions, but they should remain present and proactive, bringing clarity and direction to the project.

2. Adaptive planning

Effective Product Owners plan quickly and replan frequently. They do “just enough planning, just in time” because they understand that projects are full of assumptions about what customers want, what the business needs, and what the solution is. At the start of a project they develop a high level plan with the team in a few weeks so they can get started as soon as possible. Then they deliver in small iterations so they can test their assumptions and adapt the plan based on feedback.

3. Estimate business value

At the start of the project and at the start of each sprint the Product Owner should estimate the relative business value of the features and stories in the backlog. The Product Owner can use affinity estimation with key business stakeholders to quickly synthesize everyone’s views. When you know the relative size and value of the stories in the backlog you can organise them into releases that produce the maximum business value in the shortest time possible. Involve the technical team to ensure that they understand what the business priorities are.

4. Communicate with the team

Team effectiveness depends on good communication. To maximise communication the Product Owner communicates face to face with the delivery team every day. The best way to do this is to physically sit with the team to get involved in all the discussions that occur. When the Product Owner is communicating well with the team then the team can make good decisions about what they need to do to maximise business value and the Product Owner understands what support the team needs from the business.

5. Be decisive

The list of things that a team could do is always bigger than the list of the things they can do and this list increases as more people get involved with different priorities. The Product Owner is responsible for balancing competing priorities by constantly re-prioritising the product backlog. This means saying “no” to feature requests that have low business value. A Product Owner can deliver a product within the time and budget available if they are decisive about what features are in and out of scope. They understand that bad news delivered well improves relationships and increases trust.


The Product Owner is responsible for satisfying the customer by delivering a valuable product as soon as possible and then iterating on it to improve it. This is a leadership role where you have to say ‘no’; work within a budget; motivate teams and be across both the vision and the detail. These are just five of the many things a Product Owner could do to achieve successful outcomes in this challenging and rewarding role.

Learn more about our agile courses.

5 ways to increase your business agility

Agile is a new way of working that was created to address serious problems with the way work is traditionally done. First implemented in software development teams, the increased speed, productivity and customer focus that agile brings has seen it applied to all areas of business.

Below are a few ways to check if your business is truly agile:

1. Is your team customer focused?

Agile teams solve the customers’ problems, whether the customer is internal or external. They understand the customers’ objectives and have key performance indicators based on customer satisfaction and retention, not cost. Agile teams know that doing the right thing by the customer the first time leads to lower costs than doing the job wrong and then trying to fix it afterwards.

Product Managers have a broad scope which means that they may not be able to give the development team the time and attention they need. In this case they may appoint a Product Owner to work full time with the Development team on their behalf. If they do this they should meet with the Product Owner every few days and attend the planning and review session with the development team every couple of weeks to ensure that the development team is prioritising business value correctly.

2. Is your team able to solve a customer problem from end to end?

Agile teams contain all the different skills and functions required to solve a customer’s problem, from end to end. These people work together full time to continuously deliver outcomes that customers want. Cross functional, colocated teams are hyper productive because they remove waste, rework, delays and communication costs. An agile team that is developing a new product or service would be made up of people from sales, marketing, design, development, testing and operations colocated in one cross functional team.

3. Does your team make their work visible?

In a factory you can see the work people are doing and all the supplies and unfinished work that piles up. In offices you can’t see the work in progress which means that you can’t see the wasted time and effort in the system. Agile teams visualise the work on a scrum board or kanban board so that everyone can see what’s being worked on, what’s done and what’s next. When a team visualises their work they can manage it themselves without needing to be micromanaged. They can also see where there are bottlenecks in the system so they can fix them. This leads to faster and more productive teams.

4. Is your team regularly reviewing and improving the way they work?

Agile teams meet face to face every day for 15 minutes to discuss what they are doing and identify blockers. When they find a blocker team members help solve the problem. Every two weeks the team gets together with the client (internal or external) to review what went well, what didn’t go well and what they could do differently next time. This leads to gradual and continuous improvement in the way the team and the organisation works. Regular retrospectives are the core of agile.

5. Is your team testing and iterating?

The highest priority of an agile team is to deliver early and often.  Agile teams focus on delivering the simplest possible version of a product early so that they can deliver value quickly and get customer feedback early. Agile teams know that requirements are untested assumptions about user needs. The best way to deliver a high value product is by testing it early and often. If managers are expecting to deliver a rich, complex product in the first release then they are not adopting an agile mindset.

Teams that truly adopt agile are faster, more productive and more effective at meeting customer expectations. Agile workplaces are also more collaborative, cohesive and sustainable for those of us lucky enough to work in one.

Learn more about our agile courses.

The agile future of business

The age of the customer

We have moved from the age of manufacturing to the age of the customer. In this new age customers have more information and more choice than they’ve had before which leads to increased expectations.

In the past, businesses spent years designing mass produced products for a mass market and selling them through mass media. This no longer works. To succeed in the modern world, businesses need to quickly design tailored products for target markets, sell via two way conversations and use rapid feedback to continuously improve.

Fast-fashion brand Zara is a great example of a company that does this. Zara is surpassing competitors by releasing new items four to five times faster than a traditional retail brand. In just five days store managers, designers and commercialisation teams work with pattern makers, in the same office, to develop a concept and prototype a garment. In just two weeks, manufacturers make several thousand garments and send them to the logistics centre in Zaragoza, Spain, and from there the garments are flown to stores all over the world. This means customers can buy the latest fashion, from design to storefront, in less than a month.

How do businesses achieve agility?

Agility is a simple concept, but difficult to achieve in practice. Behind the scenes this fast delivery pace requires autonomous, empowered and cross-functional teams that are able to collaborate and adapt quickly to ever changing needs. This is where agile values, practices, and their associated benefits come in. No longer limited to software development, agile principles and tools are being applied across all aspects of the workplace to achieve faster outcomes.

Agile is fundamentally about breaking down silos and bringing people together into cross-functional, co-located, customer focused teams that can deliver solutions many times faster than before by being highly collaborative, iterative and focused. Agile methods are now used by many companies in non-technical areas such as legal, marketing, finance and customer-service areas of online companies. Companies that practice agile include Spotify, Microsoft, Google, CBAANZREA Group and SEEK.

In practice, implementing agile involves replacing slow business processes with new ways of working. Many organisations do the following:

  • Restructure their organisation so that work is done in cross-functional, co-located, client focused teams.
  • Leverage visual work tools, such as Kanban boards, to provide a shared understanding of the work in progress so that teams can swarm on bottlenecks.
  • Hold short, daily team meetings to communicate and identify if anyone needs help
  • Use two week sprints to plan and complete work.
  • Create the minimum viable product (MVP) necessary to test customer demand before investing heavily in new products.

How do businesses manage agile teams?

Managements teams need to ensure that their structure and key performance indicators reward this new way of working. Teams need to be rewarded for experimentation, learning and the delivery of business value rather than the delivery of documents. They need to know that it’s better to find out that you’re wrong with an early version of a product, than it is to find it out after huge investment of time and money.

Agile is an approach that can deliver substantial value in many areas of a business, not just software development. As we move towards an agile business future, executive, HR and marketing, to name a few, have successfully implemented agile and accelerated profitable growth.

Learn more about Silicon Block agile courses.

Speak to an advisor

How to be a good leader

We have all had good leaders and bad leaders in our careers and often people who are a mix of both. Unfortunately there seem to be far more bad leaders than good ones. This really isn’t acceptable because leadership has a big impact. Good leaders help us do our best work while bad leaders stress us out and make it difficult to do good work. Fortunately you can learn to be a good leader with coaching and experience.

As part of IE’s agile training I asked people to take part in a retrospective on managers and leaders during their careers so that we could define what it takes to be a good leader. This is what we came up with.


Good: encourages, supports, defends and rewards good work.

Bad: negative, complains, attacks and blames.


Good: coaches and trains, shares the glory, gets the best out of people and helps people move to a better role.

Bad: takes credit for other peoples work, blocks training and blocks career moves.


Good: encourages people to raise issues, discusses issues and happy to be wrong.

Bad: doesn’t listen, shoots the messenger and has to be right all the time.


Good: accepts issues, takes ownership of problems and discusses difficult issues with people.

Bad: refuses to admit there are problems, won’t take responsibility for problems and refuses to discuss difficult issues.


Good: resolves issues blocking the team, resolves conflict, calm under pressure and says no when required.

Bad: doesn’t resolve issues blocking the team, doesn’t improve team methods, doesn’t resolve conflict, is afraid of upsetting people and doesn’t challenge broken systems.


Good: understands the work, helps improve the way the work is done, challenges bad rules and poor practices, streamlines administration, makes good decisions and helps their team efficiently produce high quality work.

Bad: doesn’t understand the work, doesn’t provide enough resources to do the work, gets in the way of people doing the work, forces people to comply with stupid rules and bad practices, increases administration costs, makes poor decisions about the work and makes their teams slow and low quality.


Good: delegates, empowers, coaches, mentors and teaches.

Bad: micromanages, doesn’t trust anyone, demands frequent detailed reports, wont delegate and doesn’t coach.


Good: open, honest, encourages discussion, doesn’t tell you what you want to hear and leads by example.

Bad: manages perception, denies involvement in decisions, is deceitful and deceptive, breaks promises and says one thing and does another.


Good: understands people, cares about people, builds relationships, leaves their ego at the door.

Bad: feels entitled to power and privilege, is jealous of others, doesn’t care about people and treats people like tools.


Good: calm, organised and clear.

Bad: disorganised, poor briefing, sudden urgent tasks and frequent changes in direction.

How to reduce waste in IT – Waiting Costs


Waiting costs time and money. When customers have to wait for a product or service they are spending time and resources they could have used for something else. This means that the total cost of a product to a customer is the direct cost plus the cost of waiting. The more time you make customers wait the more expensive your products and services are.

waiting cost2

It’s the same for employees and internal customers. The total cost of a product or service to an organisation is the direct cost plus the cost of waiting. When employees have to wait for the instructions, permissions, parts or tools they need to do their job then the organization ends up paying them to do low value activities when they could be adding value to a customer.  So the cost of waiting comes straight out of profit.

When waiting becomes a regular problem people respond by hoarding which increases cycle time and inventory which increases waste further.

The causes of waiting

Waiting is caused by bottlenecks in the system which are in turn caused by a poor system and by a failure to provide the people doing the work with the information, parts, tools and resources they need.

In command and control systems senior executives usually don’t consider waiting costs because they are too far away to see them and aren’t measured on them. As a result they drive internal and external suppliers to provide products and services at the lowest direct cost even if it causes delays. One of the main ways to do this is to centralise work into large batches and send it offshore to the supplier with the lowest labour costs. The problem is that this creates major communication, quality and alignment bottlenecks which lead to high waiting costs across the organisation.

For example a high quality in-house or outsourced IT team can usually deliver a fully configured and installed test server on site for a development team in a few days for $10K with only a few hours of client input. In comparison a big low cost offshore service provider might be able to do the same thing for $7K due to low labour costs. If you install a lot of servers it would seem like you could save a lot of money by outsourcing it all to one of these big offshore companies.

The problem is that it often takes a low cost provider six to twelve months to deliver, configure and install a test server. For example one large multimillion dollar project that I was involved in was delayed because the infrastructure provider said they would be able to deliver the environments needed in six months and then took nine months to deliver the test environments and fifteen months to deliver production environments. While the team of 80 were waiting they minimised the impact by escalating to management, developing work-arounds and doing any work they could. As a result the project was delayed by six months and went over budget by more than a million dollars which was a lot better than it could have been. This is unfortunately a common experience in large organisations which happens when management don’t count the cost of waiting.

Some other common examples of waiting in IT are:

  • waiting for stakeholders to provide feedback on requirements;
  • waiting for the architecture team to review the design;
  • waiting for management to provide approval to proceed through a stage gate;
  • waiting for management to provide funding for the build phase;
  • waiting for procurement to approve a vendors statement of work;
  • waiting for another team to change a shared component;
  • waiting for defects to be fixed that are blocking a test module and
  • waiting for a deployment window.

How to reduce waiting costs

In free market economies decisions are made locally by the people impacted by them. To these people waiting costs are obvious and serious. When stakeholders and employees can choose between suppliers then they will choose the one that has the lowest combination of direct costs and waiting cost. These decisions drive down waiting costs across the organisation. As a result one of the best ways to drive down waiting times is to push resource and supplier decisions down to the users of those suppliers.

Another way to reduce waiting times is to implement the Plan Do Study Act cycle to remove blockers and streamline your work. That is to: study your process to identify issues causing delays, plan changes to resolve these issues, act to implement these changes and check the impact of these changes on cycle time.



Control charts are an important tool to help you study delays in your process. Control charts measure the time it takes to complete a cycle of your key business processes for software development and infrastructure delivery from you’re stakeholders point of view;

waiting cycle time2

Cumulative flow diagram’s are another useful tool which helps you identify which part of your process is slowing progress;

waiting cfd

Once you’ve identified the area where delays are occurring you can address it by using the following techniques.

  • Allocate more resources to the bottleneck area to increase it’s capacity;
  • Put in place a buffer before the bottleneck to make sure that it doesn’t run out of work;
  • Stop previous processes from increasing the queue of work for the bottleneck station;
  • Reduce batch sizes to improve flow through the bottleneck;
  • Use daily scrum meetings and visual project management tools such as Kanban boards to ensure that everyone is clear on what they need to do each day;

You can also increase the speed of the bottleneck station by using “Five S” to reduce wasted motion.

  • Remove all steps that add no value to internal and external customers;
  • Streamline the work process to remove any unnecessary effort;
  • Develop Standard Operating Procedures to reduce time and improve quality;
  • Continually improve the standard procedure;
  • Implement reviews and automated acceptance tests to improve reliability and quality;

Waiting is a major cost to organisations that can easily out way any benefits gained from driving internal and external suppliers to drive their costs down as low as possible. To reduce waiting costs measure them, push decisions down to users and implement the PDSA cycle.  This is well worth doing.