The Agile Practioner: The Product Organization

Ultimately, there are two fundamental types of businesses: those that provide services, and those that make and sell products. To be sure, many of these companies are hybrids of a sort. A janitorial service could mix and sell their own cleaning products and a software company may sell installation and support services. However, if a company makes products, then it is at least in part a product company.

Products can take countless shapes and forms. In the software industry, in which I work, our products are actually provided as a service to the customer, but make no mistake, we are a product company. What makes us so ultimately comes down to design. Even if we were totally outsourcing the actual production (which we don’t), we would still own the design process. It is this that I would like to expand upon here.

Agile Design

If you are a follower of the agile philosophy or are a regular reader of my Column, you know that primary focus is given to customer-driven iterative effort. Born out of Demming’s Plan->Do->Study->Act model of iterating, agile organizations conduct small experiments with real product users to learn more about their needs and optimal workflow.

Whenever possible, inexpensive models or sketches are used to bounce ideas off of potential users before beginning actual product development. This discovery phase of the process is critical to gathering the necessary information to design the first iteration.

At ITHAKA, we have three key players that are engaged during this phase of development: the Product Manager (PM), the User Research Analyst (Researcher), and the User Experience (UX) Designer. These three work closely together to define the various methods that will be used to gather critical evidence for gaining an understanding of the users’ desired outcomes.

Stephen Covey famously said “start with the end in mind” and any good design process heeds this advice. Step #1 is to assess the problems the user is trying to solve or the goals they are trying to achieve. By understanding outcomes, it frees the product team to use their creativity to achieve said outcomes.

The Product Team

If a product organization is small, it may only have one team. If it is larger it could have many teams, each designing a different product or even a different aspect of a large and complex product. For example, consider an organization like Etsy. They have a large and complex ecommerce website that not only serves buyers, but also sellers. These two completely separate user groups have vastly different needs. Furthermore, the needs of sellers and buyers can be further broken down into activities which are complex enough that each may require its own product team.

A product team, in an ideal situation, consists of every skill needed to deliver a finished product to the user. In reality, it is common practice to share some roles across teams. This may be for budgetary reasons, but it may also be because the amount of involvement for a particular role doesn’t warrant full-time engagement with one team. What is most important is that each role is filled by someone who can commit enough time to the team to remain fully briefed on all the information and learnings that are relevant to their work. Let’s take a moment to break down these roles. I am going to use software development roles, as that is my expertise, but it should be easy enough to make the translation to other types of product development where they are different.

Product Manager – in agile parlance, this person is also known as the product owner. She is essentially the chief product officer for her product. She “owns” the relationships with other interested roles and groups internal and external to the company. This could include sales, marketing, finance, as well as customer organization contacts. Each of these groups has specific needs and expectations of the product team and it is the PM that brings these to the team. The PM must also use her knowledge, experience, and perspective to help the team prioritize the work. She is also the main source of external (outside the team) communication.

UX Designer – this role works closely with the Researcher (which may be a combined role that this person has), the PM, and the developers to translate the team’s collective knowledge about desired outcomes into an actual experience. In the case of software development, this often means building “wireframe” models of the finished product with varying degrees of fidelity depending on where in the process the team finds themselves. This person is also responsible for ensuring that the proper feedback mechanisms are in place to gather evidence to support the next iteration.

User Research Analyst – research analysts could have a variety of titles, but this role is responsible for designing and implementing ways to gather crucial information about user and stakeholder needs, wants, and expectations. This could come in the form of competitive research, surveys, user interviews, or other types of interactive experiments. The gathered information is then shared with the product team in a manner that informs their actions.

Project Manager/Agile Practitioner – as this is my role within my organization, I have given considerable thought to these responsibilities. My elevator pitch describes me as a “human cow-catcher.” In case you don’t already know, a cow-catcher is that pointy thing on the front of old trains that is designed to clear the tracks in front of a moving train. In the context of a product team, this work can take many forms from basic administrative tasks, to consulting with individual team members about activities or behaviors that might be impeding the team’s effectiveness. The idea here is that this role is responsible for the general health and well-being of the team and to ensure that they are focused on continually improving their efficiency and effectiveness.

Quality Assurance Engineer – this person is not a shared resource at ITHAKA, but is in other organizations. The “QA,” as we call this person, is the leader on the team for ensuring that products are built in a manner that they can be effectively tested. Everyone on the team is responsible for quality, but others look to the QA for guidance and support to ensure they are on the right path. The QA on the team will also be the primary developer of testing platforms that ensure each iteration that is delivered to the user is free of unknown defects. Business Analyst – this role can also be combined into the work that other members of the team, such as the PM and UX Designer. The “BA” is the person the team looks to to translate complex business requirements into documentation and/or shared understanding that can be used to implement solutions. This person must have sufficient technical knowledge of the product to understand how new requirements will fit into the existing architecture.

Engineers – the heart and soul of any product development team are the engineers that actually design and build the product. In the case of software development, these people are often referred to as “developers.” This is an important distinction from a former role called “programmer.” Whereas programmers were given detailed specifications which they “coded” to make exactly what was requested, developers gather information from the other members of the team as described and use that information along with their own judgment, skills and experience to implement the product. Engineers often provide valuable feedback to the PM and UX Designer about what is possible and various trade-offs associated with the various technical approaches. The strength of these conversations is inevitably the strength of the team and thus the product they produce.

Architect – smaller organizations may have only one architect and in some cases this could be a combined role with the lead developer. In any case, it would be unusual, but not unheard of for each team to have their own architect because this role is intended to provide high-level decision-making about the fundamental structure of the product. The person in this role will need to spend a considerable amount of time reading about industry trends and new tools as well as going to conferences and networking with others to bring new ideas to the organization about how to build products better, faster, cheaper.

Data Engineer/Analyst – increasingly, product organizations find themselves swimming in huge amounts of data that must be gathered, organized, processed, and output in a form that is usable to all who may need it. There are a variety of titles and roles in this realm upto and including C level executives. In some cases, data specialists may be embedded on the team and in other organizations, they may be their own functional team or set of teams. Regardless, their work is vital to a product organization that depends heavily on evidence gathered from real users.

What Makes a Product Organization

Almost all organizations have a hierarchical management structure. Each top level executive owns responsibility for ensuring the effectiveness of some part of the organization. In the case of an organization that has embraced the idea of a “product team” structure, it is important to respect a certain level of autonomy that each team must have. Since these teams are cross-functional, it is likely that the management structure will be by function. Thus, all the QAs will report up to their functional group for guidance, as will engineers, UX designers and all the other members of the team.

Executives at the highest level will all have a special interest in the part of the management team through which the product managers report. It is here that overarching market decisions are funneled. How communication is passed through this chain of roles makes all the difference between being an effective product organization and being an old-fashioned command-and-control structure.

Whole books have been written on this topic and, in fact, much of what I describe here comes from one such author, Marty Cagan of the Silicon Valley Product Group. Marty’s two books INSPIRED and his new book EMPOWERED, speak not only to the structure of product organizations, but also the importance of having the proper type of engagement at each level of the organization. The biggest warning here is that detailed directives from high in the organizational structure will erode trust with the all-important product team and handcuff them from unleashing the full potential of their creativity and detailed understanding of users’ needs and desires.

The idea behind the product team is powerful. By creating a self-contained group that has all the skills necessary to understand what the product needs to do for users and how to build it, the organization can maximize the creative potential within the organization. There are always a lot more minds working at the team level. They are also closest to the domain in which they work. So, their deep knowledge and skill level allows them to see things that managers don’t have the bandwidth to fully comprehend.

That said, managers and executives do bring a valuable perspective to understanding the market direction and which trends and the organizational vision should be driving the choices the teams make. By communicating market outcomes the organization is seeking clearly, concisely and regularly, they support the continued alignment of the product teams around common objectives. To date, I have not heard of any approach that is more effective than a fully empowered product team armed with clear market-focused objectives.

PDF Version

Tom Bellinson

Tom Bellinson

Mr. Bellinson has been working in information technology positions for over 30 years. His diverse background has allowed him to gain intimate working knowledge in technical, marketing, sales and executive roles. Most recently, Mr. Bellinson finds himself serving as an Agile Coach for ITHAKA, a global online research service. From 2008 to 2011 Bellinson worked with at risk businesses in Michigan through a State funded program which was administered by the University of Michigan. Prior to working for the University of Michigan, Mr. Bellinson served as Vice President of an ERP software company, an independent business and IT consultant, as chief information officer of an automotive engineering services company and as founder and President of a systems integration firm that was a pioneer in Internet services marketplace. Bellinson holds a degree in Communications with a Minor in Management from Oakland University in Rochester, MI and has a variety of technical certifications including APICS CPIM and CSCP.


Leave a Reply

Your email address will not be published. Required fields are marked *