Pre product/market fit product teams: the discovery-delivery dizziness
There’s a gap between traditional agile methodologies and what’s considered good for product development. This article is the first of a series of posts exploring the tension points some product teams will face in pre product/market fit and how to deal with them.
I’ve been working with products since 2011, most of the time in cross-functional teams from startups with pre market/fit products.
In early 2017, I put together a small group of smart people to compose a cross-functional team at Incognia. The assignment was to leverage our location platform to allow app developers to make better apps for their users. In the past, we had some success hacking one product to deliver location-based push notifications for popular ride-hailing apps, so we had a hunch that this was a problem worth solving.
This initiative turned into Inloco: a product for app owners to capture and understand their users’ anonymized behavior in the real world. While most of the analytics tools focus on what users do in the app, our purpose is to link those actions with physical-world ones. Using our technology the apps become proactive, adapting them to user context.
What’s discovery?
First of all, I’d like to define what I mean by product discovery. Discovery is basically figuring out what product to build. Ideally, product should be valuable, usable, feasible and good for the business. Successful business need to be able to innovate (i.e. create new products) as fast as possible and can’t afford to use trial and error to understand how the product should look like. That said, it’s simpler to discover “what product to build” as fast and as cheap as possible and then build it.
Agile practices and methodologies focus on building or delivering software. Delivering software is the “safe state” to most software teams that are building products, specially in mature business. In addition to that, Agile methodologies optimize the delivery of working software to customers. The dizziness I referred to occurs when teams do the discovery with the same practices, tools and methodologies they used while building “already discovered” products.
I’m not sure why things went this way. Maybe it was because, in many organizations, there’s too much tension between business and tech/product teams. Boiling down discussions to the quality-scope-cost triad is quite a commonplace and may shift team focus to improve throughput rather than building the right product.
We’re addicted to software delivery
Don’t get me wrong, I know Agile was a huge step forward and I don’t even imagine how crazy it was to create products with big upfront plannings and long release cycles. But something always bothered me in the way organizations have been creating new products through Agile methodologies. It’s as if people’s attention had shifted from avoiding risk at all costs (principle of many waterfall practices) to delivering working software as fast as possible without worrying whether what was being provided generated any value.
One can tell how much importance is given to delivery through the quantity of material out there about the ways to measure a team’s velocity. Scrum introduced planning poker as the way to measure team’s velocity; Kanban matches the amount of work in progress to the size of the group, etc.
The focus on delivery is so clear that if you open whatever task management system your organization uses, you’ll see that most of the material out there talk about how to build stuff, instead of what to produce. Open questions or things that the team doesn’t know are never first-class citizens, no matter whether you use JIRA, Trello or Basecamp.
Discovery-delivery dizziness
There’s no such thing as discovery and delivery “phase”. Most of the teams are both learning (i.e. discovering) and delivering software at the same time. Both states require different personal traits, ways of working and measuring progress. In the following sections I’ll address the personal traits of discovery teams, the tools available to product discovery and how to measure progress in this context.
Personal traits
Keep in mind that not everyone in your team is going to like to take part in discovery. You should look for a mix of skepticism and good product intuition to compose the discovery initiatives.
Skepticism, in this context, is the ability to use questioning as the way to discover, not one, but many truths. Product intuition is the ability to, given a user’s problem and data, come up with useful features to solve the problem.
Product intuition is a skill: it is the observation of human behavior, trained by data, and applied to software.
“Training your product intuition”, Merci Victoria Grace
Skepticism is easy to find among software engineers, but product intuition is very hard. You, if you’re a product manager, should have product intuition and, at least initially, need to take part in all discovery processes. Remember you’ll need to be seeking people with product intuition at all times.
The art of disguising discovery as delivery
We have lots of anonymous data about user behavior in the physical world. Most of this information is completely unknown by the app owners and part of our job was to figure out how to transform that data into relevant information to them.
We’re talking about providing an analytics system on the top of a dataset that grows around 16TB per day. Offering a good user experience on this amount of data is no easy task and we couldn’t afford to build the analytics backend without a good understanding of what is valuable to the user.
After doing several validations, we came up with a set of pieces of information that could be useful to app owners. We crafted some ad-hoc queries in our data warehousing system (Presto.io) to create visualizations with real anonymous information.
All location data goes to a centralized data stream that can be consumed in real-time and ultimately goes to a cold storage: our data lake. We can query the data lake through data warehousing systems, but this approach proved to be cost-prohibitive for a near real-time scenario.
The visualizations populated with real data became the raw material for our discovery process. We created high fidelity prototypes and used Invision to validate them with our users. We also injected those visualizations in slide decks used by our Customer Success team disguising them as deliverable to our clients. Noticing the difference between the two approaches is essential. Showing prototypes with real data to users that agreed to participate in validation is riskless, but using this material as value delivery to customers may have adverse side effects (wrong or missing data, bad normalization, so on).
We’re making discovery disguised as delivery, but the output is still validated learnings.
There are also cases where the software engineers get involved in building actual software in discovery, but the goal is still learning from user behavior. The discovery process could be a real change in a product or a standalone proof of concept, but one should be aware the former may hurt the codebase (hacky code), the user interface (inadequate usability or components) and end-users (failed discovery). The team can work around the first two problems (code and design), but pay attention not to hurt the users too much; from their perspective, it’s just one product.
If your product is being successful, and your customers are OK with new things, the product is going to become a platform for experimentation and discovery, hence the design and the code should allow this. The team adopted the gatekeeper concept: most of the features being discovered are hidden by gatekeepers to prevent all but whitelisted users from seeing the feature being discovered. This practice, together with good UI components and experimentation-friendly (aka good) software architecture, helps the team to keep discovery chaos under control.
Sense of progress
Constantly changing from delivery to discovery may induce a sense of lack of progress in the team. That’s because Agile methodologies work in favor of software delivery; they don’t provide a sense of progress to discovery work.
Instead of starting with tasks definition and effort estimation, the team should work to establish the open questions. It may even be useful to start from desired outcomes and, rigorously, state hypotheses and measure outcomes.
Remember product discovery is a team job. If you’re a product manager, you should guide the process and put your product intuition in favor of the team. Make sure everyone is on the same page, knows what the questions without answers are and put some rigor on documenting them.
When there are multiple discovery initiatives in the same team, it’s important to sync those initiatives. At some level, putting discovery activities in the same place (Trello, JIRA, etc) create some alignment in the team. This is specially true if you actually split the team between delivery and discovery sub-teams.
There are lots of tools to facilitate product or feature discovery, from market research to user research. There are teams using prototyping, opportunity trees and design sprints (among others) to test fundamental hypotheses of the product. No matter which tool is being used to guide the discovery process, validated learning is the essential output of good discovery.
It’s not my intention to discuss tools for discovery here but putting some rigor on defining problems, stating hypothesis and giving the team space to work on them is the key to give a good sense of progress.
A cure for dizziness
The discovery-delivery dizziness is a tension that comes up in pre product/market fit teams. Not being clear on what state the team members are, in my experience, is the primary cause of misusing tools, methodologies or ways of working.
Seek skeptic people with right product intuition (right personal traits), set up discovery initiatives and give the team space and tools to hack their way to the right product. Ask the right questions and collaborate with them. The answers will come up.
Sometimes it’s useful to disguise discovery work as an actual product delivery. Doing so is risky, and slow, but may give the team a greater sense of how valuable the feature is. Eventually your product is going to become a platform for experimentation and this should be aligned with both engineers and designers.
There are tons of books and ways of handling product discovery out there. Steve Blank’s Four Steps to the Epiphany, Eric Ries’ The Lean Startup and the Lean series (Lean Analytics, Lean UX, so on) are all excellent references to answer the question of what product we should be building.
No one wants to build products people do not like. No one wants to create things without a sense of purpose. Systematically finding purpose is as important as delivering software and most of the teams don’t quite know the tools available.
Are you interested?
If you have interest in building location and context-aware intelligent services and products, check out our jobs postings! Also, we’d love to hear from you. Leave a comment.
