A collaborative framework for product design and development

Have you ever wondered,

• Why was I not included earlier in the product development cycle?

• Why did we waste so much time going down the wrong track, if they had just asked me earlier?

• ‘This’ makes no sense from a business perspective or engineering perspective or design perspective or product perspective - Irrespective of how you contribute to the process if you have been involved with product development in any capacity this thought has crossed your mind.

I have experienced these questions and learnt from my mistakes and flaws I saw in the process in projects I worked on. In the last few years, I have worked towards leading in a way that ensures inputs are sought and incorporated. In doing so I started to formulate some theories and frameworks that I thought might help out others in developing better products and ensuring happy team members. The framework for collaboration that I am suggesting is based on the 5D process I have written about and within the agile methodology.

I am thinking about calling it Collaborative Design Thinking (TBD) as I view design thinking as a problem solving process and not a method to create the design and it should be incorporated at all steps of the product development cycle. This framework is aimed at improving the quality of the product irrespective of which lens it is viewed with - ethical, business, maketting, design, product and engineering.

Collaborating to create a roadmap

The first step of developing a product is to conceive the product (discovery) and in today's multi-disciplinary world that is a shared responsibility that should be a part of the roadmap development cycle. A time should be allocated prior to roadmap discussions starting for anyone in the company to offer ideas based on a single criteria - an observed pain point. The pain point could be

• A personal pain point, the current process makes ‘my’ work difficult.

• A user pain point, it's difficult to proceed on the site as I cannot clearly identify how to move on to the next step.

• A business pain point, we are leaving money on the table as the data suggests when we show this feature more our revenue is higher.

It's good to have each team, irrespective of how the teams are structured in the company, to have a brainstorming session to collaboratively create a list of the pain points. This should be a company wide process driven by leadership and have a clear deadline to ensure folks get ownership in the process. The goal at this point is to identify the pain points and not the solutions.

Prioritization of the projects should be done by leadership as part of the roadmap development cycle with team leads present to champion their suggestions. It is important for the leadership team to come up with a shared framework for prioritization prior to going through this exercise as every team will have a different filter to prioritize and the overall prioritization should happen on a shared framework. The criteria for prioritization will be different for each company and will depend on the leadership’s interpretation of the company’s vision and mission.

A Product Principles framework

Many teams jump into defining solutions for the prioritized pain points, and this is natural. To ensure that this step is efficient and has buy-in from all stakeholders, it is key that there is a shared understanding of a set of guidelines or principles that will help guide the solution.

A framework I have used before (first introduced to me by my colleague, Amy Huang, and then has evolved a bit) is related to capturing the business goals and user needs, and using these along with the company's mission and vision to determine a set of product principles for the project.

Business Goals and User Needs

It is important to clearly articulate the business goals and the metrics that will be used to measure the success of these goals. The desire is to define a primary goal and 1-2 secondary goals. The business goal should not be confused with the user's needs, and the team should work at truthfully capturing the impact to the business.

The user need should be captured from the users perspective and backed by data. There may be 1-5 user needs, depending on the size and scope of the project. These are meant to capture the users expectation when they come to the page/step they are working on. There are times when pain points arise due to features being added when there is no user need and these are instances that need data to back them.

Once the team has aligned on these two pieces of information, it is very important to create a set of principles that can be used to make product design and execution decisions with minimal time spent in approval cycles.

Product Principles and Metrics

The principles help with the decision making during the design and execution phase of the project, while the metrics will determine which KPIs will be used to determine project success and how they will be measured.

The team should arrive at 3-5 principles that will help with decision making during the project. These principles should be specific without being prescriptive as the intent is to help the team working on the project and not define the solution for them. (It is ok to make changes to the framework, with the clear understanding that it could impact the timeline for the project.)

It's important to also get shared buy-in to the metrics the team is going to rely on to determine project success, as principles will not help with the measurement. Each project will have its own flavor of success metric, but I like to have one that is a combination of user success along with a business metric. Revenue per Visitor (RPV) is a good metric in many cases as it captures conversion success along with revenue impact. That said some projects maybe intended to impact a single step and in those cases conversion is a better metric to measure, especially when there are longer flows being modified.

Collaborating during the design and execution phase

It's important for the product owner, the designer and the lead developer to collaborate on the execution plan. Epics and stories can be used as an effective tool to collaborate and having all members of the team in a single tool is very helpful. This prevents data from being stored in different places and ensures everyone on the project is looking at the latest data.

The product management tools are not always the best to use to present designs to stakeholders, and it is important to get buy-in on the fact that there may be changes based on discoveries made during the development process that will not be reflected in the design deck after a certain point, when there is agreement on the key design and product decisions. This gives the team ownership to make decisions based on the product principles put in place earlier.

Also to continue to keep the stakeholders in the loop it is important to have them invited to the sprint demo’s when relevant. This gives them an opportunity to understand how far the project has come and the impact a change could have on the timeline.

Spikes and non-prescriptive stories

To have a true collaboration and leverage the expertise of members on the team, it is important to not make assumptions about any aspect of the project and having multiple disciplines contribute to a story can help enhance the product and raise the right questions earlier rather than waiting to see a finished product. Having spike stories for the engineering team to ask questions helps create a better solution from a technical standpoint and ensures that the product owner and designers are aware of any constraints that the system may put on the product.

It is always better to have stories that capture the desired outcome vs. the desired implementation. If there is an epic or story that captures the desired outcome, story or task break-up becomes a collaborative exercise between the product owner, the designer and the lead developer.

Happy teams and successful products

This process has led to happy teams and successful products and if you would like to discuss more about it leave a comment here or drop me a note on linkedin. (www.linkedin.com/in/mohandasannacharya)

Disclaimer: I have more than 20 years of experience in the product space working on designing and managing products (both physical and digital) from conception to delivery. I am capturing my thoughts here and these may have been fueled by my experience, articles I read, talks I attended, or experts I talked to and contemplation I have done based on that.