"Experience, Empiricism, Excellence"
Please share with your colleagues and friends

The People View looks at the "soft-practices" involved in communication techniques, team building, decision making, leadership and team forming. 

Product Customers are stakeholders who require value from a specific product or product family. They are typically business domain experts and are capable of making decisions on the detail and relative priority of product requirements. Product Customers perform User Acceptance functions and are ideally real users of a Product.

Close collaboration between delivery teams and Product Customers is essential to ensure that requirements are fully understood and that the right solution is being built. Product Customers must be genuine customer representatives, not a member of the development team nominated to be the customer's proxy. A common dysfunction we see is customer proxies becoming requirements authorities in isolation of the real customers. Sometimes there are multiple levels of proxies caused by organization structure and commercial boundaries. This leads to multiple levels of unnecessary translation and conversion that reduce the probability of the required product being developed.

A Requirement is a condition or capability that must be met by a system or component to satisfy a contract, standard, specification, or other form of request.

Product Customers will be involved in collaborating on the detailed requirements for a system, and their elaboration through Integration ScenariosUser Stories and tests/acceptance criteria, prioritizing Product Backlogs and guiding System Architecture. Product Customers will be involved in day to day requirements elaboration, verification and validation with builds and releases, helping a product move up the levels of Done - especially in terms of Product User Acceptance.

When building a product for an external customer base, or the open market we recommend User Experience practices and research are used to represent the customer needs. A marketing or user experience practitioner can be nominated as the Product Customer.

 

What about Business Analysts?

The people who best understand the business needs are the business users - the Product Customers. These people will understand the required business value in greater depth than a "System Analyst", "Business Analyst" or "Requirements Manager". Requirements analysts of various flavors can provide value by ensuring that all Product Customers are actively engaged, that conflicting requirements or priorities are understood and de-conflicted. Having experience in working with software systems requirements can aid analysts in prompting Customers to consider all of the various aspects of requirements (including non-functionals), tease out complexity and apply various techniques (such as story-boarding, scoping use-cases, user stories etc.) to capture the requirements.

Members of development teams with experience in requirements are well suited to this role in organizations with cross-functional teams that have a wealth of multi-skilled people. Specialist requirements professionals such as Business Analysts can add value by being excellent facilitators, strong written and verbal communicators focused on enabling and maintaining good communication between Product Customers and delivery teams - however there is always a risk that they become requirements owners, as a proxy for genuine customers, leading to dysfunction.

 

Being a good Product Customer

Product Customers will typically need to commit a large amount of time to the development of a product. In the early stages of a project, before getting to the "Product Scoped" milestone Product Customers will probably need to be committed to the delivery project full time (100%). Once the system is scoped Product Customer engagement is likely to reduce a little while the Product is de-risked (to perhaps two-thirds time) but still requiring a lot of ad hoc interaction. Once de-risked Product Customer engagement is likely to reduce to around 50% and be more focused on validation and acceptance activities than requirements elaboration and product direction.

We have seen some organizations that feel they cannot afford to release business users to act as Product Customers and so limit the time available to them for doing this critical job. Considering the large number of failed, over-budget and late projects we suggest that organizations cannot truly afford not to make business users time available to guide product development.

We recommend that Product Customers:

  • Are highly available, willing to collaborate with team members on understanding and guiding solutions at all times
  • Co-locate with the delivery team, at least until the solution is de-risked
  • Are always present at demonstrations and retrospectives - there's no point in feedback cycles if they're not joined up to the business
  • Understand software development lifecycles, especially team workflow models such as iterative/agile or continuous flow models
  • Are proactive in collaborating with delivery teams, rather than micro-managing them, to drive product and product family development
  • Have the right to make reasonable product scope and priority decisions without escalation to business customers
  • Keep requirements prioritized
  • Will be a genuine day-to-day user of the product being built
  • Are enthusiastic about the product being built

Development teams must remember that coming into the world of software development can be daunting to people without a technical background. A lot of the language is simply alien to non-developers and so Product Customers must be welcomed and involved by teams. We recommend that time is given to teach new Product Customers about the team, the technology and ways of working. Product Customers should never be scared of asking questions, their purpose is to direct the team and share their business expertise – there are no stupid questions.

 

Product Customers and Programmes

Programmes are normally responsible for delivering a number of products that work together to generate business value - a product family. Sometimes a Product Customer may work across a number of delivery teams as the Product Customer for all products in a programme. In this case the Product Customer can also expect to need to de-conflict requirements and interaction complexity across the set of products leading to more time commitment across the wider programme lifecycle.

More often there will be numerous Product Customers involved in a programme representing different products in a product family. Having a number of Product Customers involved can lead to conflicts in requirements and dependencies. We recommend the use of the Product Forum practice to manage and de-conflict multiple Product Customers and delivery teams.

 

Working with Business Customers

Product Customers are responsible for the day to day guidance of product delivery in terms of scope, requirements and acceptance whereas Business Customers are ultimately responsible for the product generating business value and justifying the cost/benefit case made in the Portfolio Request for the Product or Product Family.

Business Customers are stakeholders who the business provides value for. Business Customers can be either internal or external and are ultimately the owners of the cost/benefit case for a Product or Product Family.

Product Customers and Business Customers need to communicate regularly on the state of the project and sometimes the Product Customer might escalate significant scope issues or significant changes in delivery plans to the Business Customer as these affect the cost/benefit case and business acceptance. In the case of programmes with numerous Product Customers and even numerous Business customers we advise that the Product Forum practice is again used to manage and de-conflict scope, architecture, planning and acceptance

The Product Forum is a team-of-teams structure that co-ordinates integration of a Product or Product family.
 
The Product Forum is a self-organizing, often democratic, group that balances competing voices and concerns, owns high level Requirements and Architecture, runs the high level release stream and performing integration activities for the product. 
 

Rather than impose a hierarchy of decision making from a Programme or Project Manager downwards, the Product Forum is a "middle-out" virtual team in the middle of all stakeholders balancing concerns of Product Customers, Business Customers and Business Leadership with Programme and Project Delivery teams. An alternative management structure for cross team working (or managing a large/complex team) the Product Forum can be thought of as an agile alternative to traditional Programme Management.

Please share this page

Submit to DeliciousSubmit to DiggSubmit to FacebookSubmit to Google PlusSubmit to StumbleuponSubmit to TwitterSubmit to LinkedIn