There is a lot of literature focusing on product development, agility, methodologies, processes, frameworks and many other write-ups on anything related to building products.
This series is just a collection of personal notes, learnings and reflections on product development and everything that revolves around it. Mainly it's a collection of notes that focus on collaborative product work, on iterating and learning.
Some people view product development as a rigid process and others see it as exploratory. For some it can be a collaborative effort, for others it might be an isolated process with clear defined boundaries.
Most products evolve from trying to solve a customer problem. Sometimes the initial features are implemented by an individual or a very small team. But what happens when this small setup evolves into a large team or even teams working on these features?
At some point a different process kicks in, roles start to become more specific, specialists start to join and everything becomes more formal.
While early on there is probably a shared understanding on why certain problems needed solving, it becomes harder to keep that shared understanding over time. People might join without having the general understanding or context that the initial members had.
But isn’t making a shared understanding something of high priority?
Let’s talk about what is meant with „shared understanding“ in this context. Very often we have roles, like Product owner, Developer, QA or UX person etc., all specified with certain responsibilities within the process.
There might be a person that „manages“ a backlog of items and writes down the specifications in form of stories or in another format.
Some people might be tasked with implementing these stories according to a predefined specification. Others might create designs and layouts and user workflows based on these specs and then there are others that ensure that the implementation matches these specification or acceptance criteria.
Looking at the above scenario, is there a shared understanding?
Does everyone involved know why this feature is being implemented?
From the above scenario, the „story“ is the artifact, that should create a shared understanding. It should contain some information on the why.
On the other hand, we can’t really tell if there is a shared understanding just from thinking about that scenario. There might be no shared understanding and the specifications being the only common thread. But there might also be a strong common and shared understanding as the collective had long discussions and maybe a couple of sessions to identify and define the specifications.
What we do see, is that some type of hand-off is taking place though. A story is defined, designs/workflows/mockups are created, these are then handed-off to a different group that does the implementation. Once the implementation is done this is handed-off to the next group that ensures the solution is on par with some predefined standard. There might be more hand-offs involved, like passing the implementation to ops, to run the solution and so forth.
Is there a more effective way to generate a shared understanding though?
Let’s think about some scenarios. In Scrum for example, it’s the development team and the product owner. Two separated entities, that meet at a pre-defined meeting like the sprint planning.
But why is there a built in hand-off from the very start?
This might be due to historical reasons, mapping back to classic project management, which was tasked with managing the people and the project. The more modern version is a product person managing the product, but not being part of the implementation team.
But who should be part of that team?
Before we try to answer that question, maybe it would be interesting to start from the customer and work backwards from there.
A customer might need a solution for editing some profile information. Who could understand the actual problem inside the organization?
Multiple people come to mind. Let’s think about this for a moment. It might be sales people, who have information about recurring potential customer requests, but it also might be customer support, which could identify some problems in the workflow or user experience, or hidden features disguised as bug reports.
It might be some marketing person, analyzing help docs or blog posts, that might touch the topic, that customers need solving. But it also might be a product person, that has collected data and is always talking to customers. It might also be a developer that would write some queries to detect how a specific feature is used. It could be a QA person, but it also could be someone from UX, some designer, literally anyone might be able to provide some insights.
But how do we approach it commonly?
We mostly have a specific role that identifies features, that writes down these features and that prioritizes these features. So the information is mostly tied to a specific role. That role should ensure that the right things are built and that everyone understands what is needed to be done, so that the feature can be rolled out to the customer. So a shared understanding now might be tied to that specific role, and the quality of that understanding varies on how well communicated this is, be it in person or via an artifact.
But what if thought about this from a different perspective?
What if the team consists of a diverse range of people with varying expertise?
Obviously there is a thing called „cross-functional“ teams, or t-shaped professionals, but let’s not focus on this too much for a minute. Let’s think about how a team could create a shared understanding and collaborate based on that understanding to come up with a solution, that might solve the problem more effectively. Instead of having a fixed meeting once per iteration, there might be an ongoing discussion and iterating on the problem. Before jumping into the first solution, there might be room for iterating on possible options, on asking further questions and coming up with a better solution.
A team could consist of anyone, that might be able to contribute to the problem and solution or a specified domain or the work to be done. The earlier everyone is involved in the process, the earlier a shared understanding can be manifested.
But let’s map back to the original customer problem. The customer is not really interested in how the solution is sourced, how the process is organized, if we use story points or write stories in general. What the customer is interested in, is having the problem solved.
Keeping this in mind, we can see that there are some opportunities that come with creating a shared knowledge within a team. A team dialog could create more effective solutions, which could lead to less silos and hand-offs.
Synchronization is underestimated. If the knowledge is spread all over the place, it would require continuous synchronization, to leverage the collective knowledge and skill, furthermore, there might be a lack of context, once knowledge is passed down from one individual to the next. As the context keeps changing, there is a continuous need to translate the context to everyone involved. A side-effect is mostly needing more and more meetings to keep everything synchronized.
So what if we identified the problem and are able to quantify the impact, but also include quality aspects into our thinking from a product perspective? What if we are able to build a team of diverse people that can ask customers questions, that can collaborate with the customer, invite the customer to sessions and so forth?
What if we didn’t care about roles and more about who can contribute to the solution?
Seeing it from this perspective could mean the following: a strong focus on the complete line of work needed, from exploration to delivery and maintenance. This also means making the complete process transparent, including where does an idea come from, why is it moved to exploration phase, how is the decision behind making this a worthwhile investment to implement it, what are the metrics for validating that this feature is actually useful and adding value. It would require
shifting from hand-offs to collectively understanding the problem and working from there.
At the end we’re building things to solve problems, not to show some reports or charts based on isolated metrics that have nothing to do with actual customers.
This requires a different way of thinking about the work, it would require moving from focusing on strict workflows to focusing on the work that actually needs to be done. It would require to ask the right questions: „What benefit does this meeting have?“, „Who can contribute?“ or „What are the metrics for the decision process?“.
If we can map back everything to actual customers, we can ask „How does this make the customer’s life easier or simpler or better?“
It would also enable us to value learning. One constant goal might be to learn more with every exploration. Learn more about our customers, learn about how to identify better ways of solving problems.
If anything, we should try to improve shared understanding. Make the information transparent, enable everyone to contribute in a sensible manner and leverage the collective group knowledge for continuous improvement.
If you have any questions or feedback please leave a comment here or connect via Twitter: A. Sharif
Top comments (0)