Work like a Lean team, and don’t get locked down by roles and responsibilities

The best product gets delivered from an efficient and flexible team, where everyone is responsible for building and delivering a meaningful product. Working as a team is all about exhibiting professionally mature work culture where everyone self-governed and free to ask questions and get the satisfactory answer in no time.

Effective team is like a machine, where every part constantly communicating with each other, in-order to produce something meaningful and delighting, which solves real user problem.

Introducing work culture is easy, but maintaining culture is tough. The team is not always constant, and it keep on shuffling with leaving old members and joining new members. Everyone comes with their own understanding and perception of what’s culture. It’s important for a team to onboard new members with common understanding of what culture actually mean to this team. Don’t mess or let it get messed up, great work culture helps in building a successful product with delightful user experience.

There is a clear differentiation between ownership and responsibility. Responsibility is a shared task or combined effort, where every team member is responsible for delivering a useful product in wholesome. Whereas “Ownership” can’t be shared, and should be owned by someone in particular who is best suited for it. Of course ownership doesn’t mean one person owns complete end to end product development and delivery, it’s responsibility of all the team members. Ownership here refers to a different component of the development system, like Requirement gathering, Feature development, Interaction Design, Visual design, Front-end and Back-end developments, team management and function ownership etc.

Let’s look into some popular roles and responsibilities in software development.

Product Manager:

Product Manager is the face of a product, who represents the team to higher management, and similarly represents the customer to the team. Product Managers work with the Product Owner, development team, customers, senior managers, sales and always keep an eye on the wider market, including competitors. Product manager constantly works with Product owner, to make sure product development is user informed and the backlog is reflecting the same. It’s product manager’s primary job to be in touch with the customer constantly and keep on iterating roadmap based on user feedbacks.

Product Owner:

Product owner is responsible for project success and leads the development efforts by maintaining the prioritised backlog. Product Owner constantly works with Product Manager to keep the backlog always prioritised, developers can pick top-most items/stories in order to work on. It’s product owners responsibility to make sure there is always enough work for the scrum team, and should be able to answer why they should do that work, what user value it’s adding in the product. All the necessary assets, content and information for development should come from Product Owners.

Programme Manager:

Programme manager’s job is to do the project management. Project Manager should know in and out the product, all the skills, tools and techniques required to run the development successfully. Programme Manager is responsible for initiating, planning and closing the project. While development is in progress, Program Manager has to monitor it day-to-day basis and make sure everything is under control.

UX Designer:

UX designer is responsible for the success of the product by solving the user’s problem and delivering the feel good factor while using the product. The broad responsibility of UX designer is to define the interaction workflows and making sure every detail has been thought. UX designer has to wear multiple design hats to make sure the product is functional in a meaningful way and simple enough to use. One thing is important to understand,

Visual design could be responsibility of UX designer but necessarily nothing to do with UX designer role.

Target Market:

The target market is a specific segment of users that is being targeted by a company with its product, services and marketing campaign. Target market is defined by age, social, economic, demographic and psychological factors.

Scrum Team:

Scrum team is a collection of individual contributors, working together to deliver the product in incremental order as dictated by-product owner. Scrum teams are usually small, ideal size is 5–7 individual contributors.

User Researcher:

Getting the right information from the right user is not an easy job. User Researchers are the dedicated resource in a project, focused on understanding and communicating user behaviour and needs of the product. They run the qualitative and quantitative research on a product, to make sure the team is building the right product. They help in product hypotheses validation/invalidation.

Learning Experience Designer:

Learning Experience is directly linked to the adaptability of your product. Very often Learning content designer misunderstood as a responsible person for of any kind of content/ terminology used in a product, and their job is to make content understandable to target user. In reality, Learning Experience is a combination of Instructional design, education pedagogy, human cognition, understanding of user habits, social science and user experience. They are responsible for making the product useful and easy to adopt.

Visual Designer:

Responsible for all kind of visual communication in a product, and setting the tone/theme of the product. Visual Designers primary job is to set-up the visual guidelines by creating visual pattern library, and delivering all the required assets for development. They are responsible for planning and projecting product/feature ideas and experiences with Visuals and Textual Content.

Software Architect:

From Wikipedia “Software Architect is a software expert who makes high-level design choices and dictates technical standards, including software coding standards, tools, and platforms.” Software Architect is responsible for product’s technical success or failures.

UX Architect:

UX Architect is a relatively new role and introduced to strengthen the User Experience aspect in the product development process. UX Architect needs to work with Product Manager to create a high level of the design brief, and deliver to UX designer and Product Owner to get it detailed out. UX Architect decides the experience theme of the product, usually by creating Interaction pattern library, design principles, innovation and technical inputs. UX Architect at some level should be familiar of technologies being used in the product, by working with Software Architect and Development team.

Scrum Master:

Scrum master is a challenging job. It’s job of facilitating the process information flow with-in the scrum team. This is additional ownership apart from being an individual contributor. Any individual contributor (UX, QA, SWD) can take this responsibility, with only constrain that scum master should be always with the team, all the time.

Some of the most frequently used terminologies and what they mean.

Hypotheses:

The assumption made about product or particular feature, and it can be any kind or related to anybody in the context of that product/feature.

MVP:

A minimum and useful product/feature which can be presented to users to work with in order to get early feedback. Minimum doesn’t mean useless and non-viable product. It has to deliver intended functionality in smaller pieces but always usable. MVP should incremental and iterative i.e. it should be flexible enough to incorporate user feedbacks.

Validation:

It’s process of measuring the hypotheses in right scenario with the right kind of users. Validation results are not necessarily always success, it could be failure too, which means your hypotheses was wrong and just got invalidated. Invalidation is good, it helps you in early realisation that you were building something which nobody was going to use. If successful, go ahead start building next phase of it to test again with users.

Analytics:

Analytics is all about ability to collect data and using them in meaningful to make your product more desirable. Data can be any kind, usually related to user, which can help making product decisions in order improve business metrics.

Qualitative Research:

Qualitative research is most effective way to construct hypotheses. It uses in-depth engagements with a small group of people, who help in guiding the hypotheses creation. If you already know the problem, it helps in generating ideas to solve that problem. Qualitative research results are mostly descriptive, rather than predictive in nature.

Quantitative Research:

Quantitative research is all about generating data around different opinion, usage pattern and in some extent on user behaviour. Quantitative research is good for finding the good and bad parts in your product, but it doesn’t provide any insight on why something is bad, and ideas around how to fix it.

Interaction Design:

Interaction design is a medium to connect the digital space to a real human to complete a certain task. Interaction is always two-way, where human does something in digital space(Input) and digital space generates the response (Output). Interaction Design addresses the workflows and supporting artefacts required to perform a user-initiated process in a system.

Team Structure, wearing multiple hats when needed

Depending on project complexity and resource availability, roles and responsibilities keep on shifting and many time same person has to wear multiple (role) hats. Here are few common role configurations, often you get to see in any product development environment.

1. When UX, PO and PM roles are played by same person

Nothing can be better than this if you are working with “Lean Team” on relatively smaller size of project, and everyone striving to deliver just one product which solves just one real user problem. All the communication will be always 100% pure, and the product is always developed the way user want to use it.

Pros:

• One interface/communication channel between user and developers
• User input will be always communicated in pure forms
• Design/Interaction patterns will clearly reflect the deep understanding of user problem
• Less and more productive meetings
• Faster decision-making (always)
• Product development is aligned with company’s vision

Cons:

• Depending on project complexity and size, can be overkill for someone
• If owner can’t handle all the responsibility, can turn out to be mess
• Justifying every responsibility can be challenging
• Product can be turned out to be someone’s vision, rather solving real user problem
• Product can be user driven, rather user informed

2. When PM and PO roles are played by same person

This works well, again depending on the team culture and project size. This will allow clear understanding of user problem, and carefully thought/validated solution.

Pros:

• Faster decision-making
• User problem clearly communicated to UX, for designing best possible solutions
• Coordinated communication between user, designer and developers
• Prioritised backlog, always reflecting the user inputs

Cons:

• Justification can be challenging to both roles, as PO need to constantly work with development team, and should be always available
• If problem is not clearly communicated to UX, can lead to confusing user experience design

3. When UX, PO and PM roles are played by different persons

This can be the ideal scenario, where every role is having complete ownership of tasks, and each owner can do justification to assigned role. Sometimes it leads to confusion between UX and PO, UX provides the solution which need to be got implemented under the guidance of PO. This needs a really good sync and synergy between UX and PO, to make sure development team understands what solutions they are developing and whether it’s solving user problem or not.

Pros:

• Complete ownership of reach role
• Everyone get enough time to justify each role
• If everyone is in sync, can deliver best user experience
• Everything well documented and clearly communicated

Cons:

• Personal conflicts
• Lots of meetings
• Everyone tries to prove their capabilities and forget about real user problem
• Occasionally product suffers for bad user experience

4. When UX and PO roles are played by same person

Most of product development happens in this structure. It’s the best use of resources, UX knows what matters for product and guides the team to build a product as PO, which truly solving a real user problem with delightful user experience.

Pros:

• Development team directly works with Designer
• Backlog reflects what matters for user
• Occasionally Designer convinces team to develop small but wow factor in product
• Backlog is prioritized to reflect incremental building stages
• Good sync with PM can lead to success

Cons:

• Designer need to justify PO role and convince team that he/she is part of team
• As a PO, designer need to participate in technical discussion
• Some time designer get constrained and carried away with technical debts, and compromises with user experience

5. When UX and PM roles played by same person (it doesn’t make any sense)

This can be messy and biased. The chances are that team will have no idea what they are building or whether it’s right product or not. Hard to see this kind of structure in a team. Probably it will end up user driven, rather user informed.

Conclusion: No matter what team structure you are following, if everyone is justifying their job and working towards solving user problem in a meaningful way, the team will always deliver a desired and delightful product. Just make sure communication channels are less cluttered and information is flowing in its pure form, and everyone is understanding what user problem they are trying to solve.