Our hypothesis for metafolly
Building a successful product that resonates with your customers and a product that they value and depend on starts with learning about your customers, who they are, developing a deep understanding of their problems, their desires, and their aspirations.
Simply said, it starts with talking to your customers. You have to understand what they are trying to accomplish, what jobs they are trying to get done. The goal is to discover their problems and identify related product opportunities.
It would be a folly (no pun intended) to consider talking-to-your-customers as a one time exercise. You have to keep at it, the learnings have to be continuous if you want to keep yourself grounded in your customers’ reality, if you want to drive empathy towards your customers to ultimately build solutions that they value.
Now, you should listen to your customers, but you shouldn’t be taking requirements from them. While customers are generally good at articulating the problem symptoms, they are not necessarily good at understanding the underlying core problem. So while their ‘requirement’ might be a solution to their specific symptom, it might not necessarily solve the underlying problem. Moreover, you don’t want to build a series of customized solutions, but rather a solution that works for a large set of customers.
So if talking to your customers doesn’t linearly result in deriving customer requirements that you can easily add to your product backlog, prioritize and schedule for delivery, how else do you get to your actionable list of things to build next? That’s the hard part.
Connecting The Dots
Understanding customer problems and deriving insights that form the basis of innovative solutions are all about pattern recognition. While flat files and a linear workflow can help you document raw qualitative material from customer conversations and interviews, and while they might even allow you to sift and segment this data to a certain extent, their inherent structured nature is not best suited at connecting dots and identifying patterns.
Instead, we imagine a platform, a fluid space where the product teams can ingest qualitative customer data; sift, segment and sort through it; look at key observations from multiple dimensions, and intuitively create, arrange and rearrange visual mappings to realize new perspectives. Such a free-form, visual medium would allow you to take in the big picture, zoom in and zoom out as you please, and freely move back and forth in a fluid manner helping you spatially navigate through multiple data points, and thereby establishing connections and letting patterns emerge. After all, this visual and spatial way is really how our brain innately processes and makes sense of large and complex sets of information.
Shared Understanding. Shared Learning.
We imagine spatial boards that allow you to externalize your thinking; visual mappings that spark conversations and help you create shared understanding across your product team (and by the product team, we mean product manager, designer, and engineers). Such a platform would not just bring about a behavioral change of getting the entire cross-functional product team, including the engineers, closer to the customers and their pain, but also in collectively brainstorming through various possible solutions. You would then no longer hand over solutions to your engineers and do their job for them, but together you would figure out what needs to be done. You would learn together.
And we would argue that this board with both, the context and the solution mapped out, is your product requirement document, your user story. This is where you start building from. This is the lean product playbook at play for real.
This is our hypothesis for metafolly.. a collaborative brainstorming platform for product teams to discover customer problems and product opportunities.
One thing we’re certain of… As we continue talking to our customers, prototyping and building metafolly, we will keep learning and we will keep refining our problem statement.
