Thanks to the hard work of Dennis Crothers, Michael Ogrydziak, and Ryan Aipperspach, the first version of Double-Loop is ready for early users. This post is meant to explain why and how to use version 1.0. If you’d like access, please fill out the form at the bottom of the post. And thanks to Peter Fenyvesi for suggesting I create a page like this!

Why use Double-Loop 1.0?

The hypotheses of Double-Loop 1.0 is that your product development process will continually improve if you enact the following key behaviors.

Behavior #1: After each launch or event related to your product, record what happened and its expected impact.

Consequence: You will design each new iteration with clearer objectives and measurable hypotheses.

Behavior #2:  When time passes after a launch, loop back to capture the results relative to the expected impact.

Consequence: You will discover false assumptions in your thinking. You will improve your ability to design and forecast successful launches moving forward.

Behavior #3: Allow all team members to read and author the history of your product.

Consequence: Your company’s collective knowledge of the product will increase along with confidence in product development efforts.

Double-Loop will provide you the support and structure to consistently apply the above behaviors and reap the rewards. By helping you create a history of your company’s past launches and learning, Double-Loop will transform your company’s ability to make the right bets moving forward.

How to use Double-Loop 1.0?

The purpose of version 1.0 is simple: use Double-Loop to build a timeline of launches and other events related to your product. To illustrate, here’s a portion of the timeline we’ve built at my company.

Creating & Editing Events

As soon as you accept your invitation, you will arrive at a screen where you can create your first event. An event can be a launch, or anything that might affect your product like a marketing campaign, news story, or Google algorithm change. For each event, you can record the summary, details, expected impact, tags, team, and screenshots. Each event will be viewable in your overall timeline and on its own dedicated page. You can edit previously created events to add results or make any updates.

The largest barrier to finding value in Double-Loop 1.0 is the potential resistance you might have to recording events every time something happens relevant to your product. We have plans to address this (see the “Increase Stickiness” section below), but in the meantime I urge you to stick with it by consistently recording events and notifying your team of updates. As your timeline grows, the value compounds. Soon, you will enjoy creating Double-Loop events as a satisfying post-launch ritual.

Adding Team Members

Double-Loop grows in value with each new team member that joins. To invite folks, click the “Team Members” link in the top navigation and provide their emails. All team members will be able to the view and edit the timeline.

Adding More Timelines

By default, your Double-Loop subdomain is loaded with one timeline titled “General.” Like with Slack channels, it’s advisable to be conservative with adding new timelines. If you do want to add more timelines to a support a bigger team, click on your user menu in the upper right of the top navigation to find the “Add timeline” option.

Future Versions of Double-Loop

We’ve been using Double-Loop at my company for a few months now and it’s become indispensable. It took a bit to get in the habit of recording events, but now that we have a history captured, Double-Loop has helped us be more methodical in our product approach, connect changes in our metrics to deployments, and communicate our impact to the broader company. That said, there’s a lot more to come which I place in two buckets: increasing stickiness and growing the value proposition.

After you spend some time with version 1.0, I would love your thoughts on how to prioritize the many possible enhancements. New ideas are welcome too!

Increasing Stickiness

These features are intended to keep Double-Loop in the forefront of your mind.

• Integration with your deployment process. Add a Double-Loop API call to your deployment script to automatically create events with releases.
• Integration with project management software and GitHub. Automatically populate launch events with release notes generated from project management tasks and code commits.
• Slack integration. Slack notifications when new events are created and automated reminders to update the results of previous events.

Growing the Value Proposition

These features are intended to increase your motivation to store your product history in Double-Loop.

• Analytics integration. Add graphs from services like Google Analytics above the launch timeline to help you connect product events with changes to key metrics.
• Search. Search and filter using all event attributes; team members, tags, etc..
• Screenshot annotation. Streamlined workflow for taking screenshots of launches and annotating pertinent details.

 

Wanna give Double-Loop a Try?

–> Take this survey

 

See my answer to the Quora question What’s something product managers know that others don’t?

 

Ostensibly, building a product implies creating value through addition. But each extension of a product comes with a risk of unintended subtractions. Some ways to fuck up a product are obvious, like introducing horrific bugs. Other changes create tensions that lead to injuries down the road. The nature and maturity of a product influences the company’s tolerance of risk. E.g., in 2014 Facebook changed their motto from “Move fast and break things” to “Move fast with stable infra[structure].” But all companies, conservative or aggressive, should at least be aware of the particular pitfalls they face while pushing forward. Towards this end, I created a map of the dangers facing products builders.

 

The product triangle, with vertices for technology, users, and business, is a device for representing the interplaying dynamics surrounding a product. Within this Map of Ways to Fuck Up a Product, each danger is adjacent to the affected vertices of the product triangle. Six of the dangers involve breaking connections between two of the product vertices. Three of the dangers are “tensions” resulting from competing forces tugging at a vertex.

Breaking the connection between technology and users

These problems prevent users from accessing or understanding the product’s value.

Bugs. The technology doesn’t work as intended, in severe cases blocking critical user flows.

User experience flaws. Even when a product functions properly, its value can be obscured by design problems.

Breaking the connection between users and the business

These problems prevent a company from converting product usage into business value.

Inability to monetize. Even when users embrace a product they may not (1) be willing to pay for it or (2) be considered valuable by advertisers.

Growth engine failure. The user base is too small to create sufficient value due to lack of organic growth measures (e.g, viral mechanisms, SEO) and the cost of paid acquisition is too high.

Breaking the connection between the business and technology

These problems prevent the company from adequately producing the product technology.

Insufficient budget. It’s too expensive to build the technology that customers want.

Execution failure. The product team, due to failed process or technical snafus, is unable to build the technology within business parameters.

Tensions

Tensions at each vertex, left unresolved, lead to the broken connections with neighboring vertices as described above.

Technology tension. The combination of business parameters and customer desires is technologically insoluble; e.g., resulting in worsening technical debt.

User tension. The actions necessary to monetize the product are at odds with the user experience. A prime example are advertising-driven companies where the needs of advertisers (to grab attention) clash with the needs of users (to consume content without distraction).

Business tension. The value captured by the company and the cost of producing the product is out of alignment with business expectations. There is business tension when (1) a mature company is losing money when it is expected to be profitable; or (2) the progress of an early stage company (perhaps measured in audience growth rate) falls short of investor expectations.

---

 

There are strategies for avoiding the dangers described above. For insight into how to not fuck up a product see my posts A Visual Vocabulary for Product Building, The Product Management Triangle, A Map of White Space for Product Managers, and Principles of Startup Team Design.

 

Most people that work for a company have ideas for how the product should evolve. Product managers serve, in part, as a gateway for product changes. This requires filtering, crystalizing, and prioritizing the ideas that emerge from across the organization. Product managers are biased to act on suggestions that cohere with their own vision. But they are also conscious of company politics. While strong PMs will push back on flawed directions from any source, a request coming from (e.g.) a prominent executive is more likely to receive attention, regardless of its merits. A product manager is more likely to respond to an idea from a friend than from other coworkers.

Regardless of how a product manager selects ideas to move on, it is subject to bias. A PM’s selection bias, and how it is perceived, can be detrimental to an organization. While PMs, in theory, have the best informed perspective on how a product should evolve, they inevitably have blind spots. Breakthrough ideas can be filtered out, resulting in tragic missed opportunities. And when the rest of the company watches seemingly “bad” ideas get prioritized from executives or from friends of the PM, faith in leadership is eroded. The company at large wants the best ideas to be acted on, not political maneuvers or popularity contests.

PMs should strive to eliminate the risk of their own biases. They should appreciate that their own intuitions for the product can be wrong. While an ability to conceive and identify the most promising product ideas is invaluable, a product manager must also create an environment in which the merits of ideas can be objectively measured and understood by all. This requires creating clear success criteria for product changes, investing in comprehensive analytics, and consistently looping back to all previous launches to compare their actual impact (or lack there of) to the expected impact. When a scientific framework is achieved, political dynamics may still taint which ideas are tested, but at least folks will feel confident that only winning ideas will persist in the product. The CEO’s suggestion will be killed if it fails and the intern’s invention will be shipped if it proves successful. The process of analyzing the success or failure of all launches will bring the company together on a shared learning path.

While installing a rigorous process for testing product ideas is vital for a healthy product organization, the ultimate political stress reliever is to create an abundance of which ideas can be tested. Companies should invest relentlessly in increasing their experiment throughput. Tools like Optimizely are designed explicitly for this purpose. Content management systems can be deployed to make it easy for non-technical team members to try content, graphical, and layout variations without pushing new code. I anticipate we will see an increasing number of artificial intelligence systems, like The Grid, where product changes are conceived, not by humans, but by machines, exploding the realm of possibility.

PMs should create environments with objective measures, maximum serendipity, and minimum subjectivity. In fact, the PM doesn’t even need to know why a product change succeeds. The PM just needs success.

 

 

Many fundamentals of product development are straight forward in theory but difficult to apply reliably in the real world. With each launch, teams should define clear objectives with measurable success criteria. They should communicate launch strategies and details to the broader company. After time passes, they should analyze whether a launch met success criteria. Periodically, teams should step back to evaluate the efficacy of their overall process and identify opportunities to improve.

Teams who consistently apply these practices will continuously improve their ability to ship successful products and build the company’s confidence in their efforts. Yet few teams do. Under the pressure of running a business, fundamentals slip through our fingers. We launch changes we believe are valuable without formulating clear, measurable goals. We get too busy to bother informing the broader company about what we’re doing. Focused on the future, we often neglect to loop back to assess previous launches or reflect on our engrained processes.

Even after building an appreciation of best practices in my 10 year product management career, I often find that, to the detriment of my company, applying them is too cumbersome to actually do. This is why I’m driven to create Double-Loop. The vision of Double-Loop is to make it easy for teams to follow, and keep following, the fundamentals of product development. Double-Loop will transform teams’ ability to learn from their launches and make the right bets moving forward.

Double-Loop records a historical timeline of events related to a product or suite of products. An “event” could be a code change or any type of happening relevant to the product such as a marketing campaign, news story, or Google search engine change. Events are added either automatically when the company ships code or manually by any member of the team. The record of each event consists of a summary of what happened, details, visuals, people involved, and the expected impact to the business. When time passes after the event, the team loops back to record the actual impact of the event.

While teams will be motivated to update their timelines, Double-Loop takes measures to increase the likelihood that they do. Double-Loop will be integrated with the team’s deployment process, code versioning (e.g., GitHub), project management software (e.g., Pivotal Tracker), and communication platform (e.g., Slack). Every time the team team ships code, an event will be pre-populated in their timeline with the set of code commits and changes pre-populated. Double-Loop will then ping the team to go into Double-Loop to provide more information on the launch. Or a Slack bot will ask questions about the launch, allowing folks to fill out details in Double-Loop directly from Slack. When time passes after the launch, Double-Loop will remind the team to assess the impact of the launch and update the event record accordingly.

Double-Loop will provide beautiful interfaces for the overall timeline and events. Teams will feel proud to share their pages in Double-Loop with their company. Double-Loop can be configured to automatically send emails or Slack messages with the addition of each event. As a side effect of using the the tool, Double-Loop will take care of launch emails and release notes that were otherwise extra work to generate.

I’ve been using the first version of Double-Loop in my current product management role. The process of keeping a timeline has made me a better product manager by itself. Double-Loop nudges me to fully articulate the context of each launch and close the loop on assessing impact. These are critical activities that I neglect when pressures and distractions mount. Also, the historical record has allowed me to better interpret our web analytics, lead team postmortems, and prepare for board meetings requiring a narrative of what we’ve accomplished.

The benefits I’ve experienced thus far are just the beginning of the value that Double-Loop will create for companies. Double-Loop provides a longterm memory store that will help new team members rapidly catchup with organizational learning. As contributors seem to be coming and going from companies at an increasing rate, Double-Loop will ease the transitions between the old and the new. Double-Loop increases the value of each of a company’s launch by maximizing the amount of learning retained.

While the first target users for Double-Loop are software development teams, the applications are broader. Any type of organization that would benefit from a recorded history will be able to leverage Double-Loop. However, I’m particularly compelled by Double-Loop’s utility for venture capital firms. If you’re a VC, imagine if every startup in your portfolio kept a Double-Loop timeline. You could more effectively provide advice based on the narrative of their history. And when a startup does go down in flames, their Double-Loop timeline will be like an airplane’s black box. A VC could make the timeline from a failed company available to other investments attacking the same space, thus increasing the chance of their success.

Are you interested in trying Double-Loop?

If you would like to be an early user, signup using the form below.

Hierarchical thinking makes our western minds feel comfortable. When looking at the messy, apparent randomness of the world, we find ourselves searching for core truths that, when understood, make everything seem clean and logical. We want principles that fork into sub-principals like tree roots. Sometimes this impulse pays off big. Science and medicine are rewards for breaking phenomena down into parts and sub-parts whose behavior can be explained and predicted. In the industrial age, companies thrived in the form of hierarchical structures in which the role of each low-level worker is explicitly defined by managers sitting at the top. In the industrial age, the boundary between human and machine became blurred.

While humans continue to extract deep value from hierarchical thought, our reductive tendencies can go overboard. Venkatesh Rao has explored this notion through the concept of “legibility.” To satisfy our deep desire for the world to be legible, we impose our own structures on behaviors we don’t understand. As discussed in James C. Scott’s book, Seeing Like a State: How Certain Schemes to Improve the Human Condition Have Failed, this tendency has led to disastrous consequences in the realm of statecraft. The U.S. government’s attempt to create order in the middle east illustrates the point. Rao summarizes the recipe for legibility-based failure:

• Look at a complex and confusing reality, such as the social dynamics of an old city
• Fail to understand all the subtleties of how the complex reality works
• Attribute that failure to the irrationality of what you are looking at, rather than your own limitations
• Come up with an idealized blank-slate vision of what that reality ought to look like
• Argue that the relative simplicity and platonic orderliness of the vision represents rationality
• Use authoritarian power to impose that vision, by demolishing the old reality if necessary
• Watch your rational Utopia fail horribly

So when should we apply hierarchical thinking and when should we avoid it? This question is especially puzzling in the realm of software development. Rooted in computer science and analytical modes of thought, software has internal logic that can be well understood. You can solve big problems by breaking them down to smaller problems.

Yet we’ve seen the desire for legibility get software companies into trouble. A primary example is the waterfall model of development. It’s a lot easier to run a business when the outcome, cost, and timeframe of each project is clear. With the waterfall model, companies try to achieve certainty through completely defining requirements upfront and estimating the corollary engineering work. While the outcome of running a line of code can be predicted, the industry has learned that the outcomes of complex software projects, even with heavy analysis, cannot be. Nobody can predict upfront the exact set of human or technical challenges. Waterfall projects lead companies to spend fortunes on failed software.

With the advent of Agile, we’ve seen companies trade in legibility for results. Learning and course adjustments are baked iteratively into the agile process. In the agile model, companies are less certain about exactly what they are building upfront. This can be hard for some people to accept, but they can be more certain that value will come out the other end.

The venture capital model provides another example of choosing results over legibility. In venture capital, it’s understood that, to discover how software can transform an industry, the most successful approach is not to conceive and flesh out the one big idea. Instead, the winning approach is to make many bets and let time be the judge. We don’t need to know why company X will hit a home run while similar company Y will strike out. We just someone to hit the home run.

While agile and venture capital demonstrate that the software industry is learning how to manage uncertainty, companies still try to exert too much control over the future unfolding of their products. Product managers are commonly expected to create “product roadmaps.” The roadmap metaphor suggests that teams are driving down a defined road that will lead to certain projects, like passing by gas stations. There can be forks in the road, but since you have a roadmap, you know in advance what you’ll get in each direction.

It’s ironic that the same companies who embrace agile create product roadmaps offering static views of the future. In my experience as a product manager, roadmaps are bullshit. They are created to make the company at large feel comfortable with where the product is going. Roadmaps make the product evolution legible. But inevitably, the experience of each project completely changes the trajectory. Things you thought were important aren’t. Things you previously neglected are vital. Things that you thought would be technically easy were hard, and vice versa. The unfolding of new knowledge does not just dictate which road on the map to take, it renders the map meaningless. I concede that, in the case of mature software with a long backlog of clearly valuable feature development, roadmaps have value, especially in managing the expectations of external clients. But if you’re trying to build something truly new, whether you are a big company or startup, roadmaps create the illusion of certainty at the detriment of success. If the PM can tear up and regenerate their roadmap at each iteration, they are relatively innocuous. But if teams are actually held to their roadmaps, they’re toxic. Product builders must be given the freedom to be maximally adaptive.

So if we don’t do roadmaps, what do we do instead? I’m not entirely sure yet. In my current company, I just say what we’re doing next and keep a list of all the things we could be doing but aren’t. The collective imagination of a company should be captured, just not with flawed forecasts for dreams becoming real.

In a world where a piece of writing will only get traction if it can be teased effectively in a tweet, it’s possible to invest significant effort crafting an article that will barely see the light of day. Thus, I’d like to incorporate readers earlier into my writing process so I can gauge interest in potential subject matter before I make the decision to flesh out an idea.

The poll below provides some possible directions for my next post.  Please choose the one you find most compelling, or add your own idea. The results will dictate my next focus area.

See my answer on Quora.

The spectrum of design skills necessary to create successful software applications has been chopped up into an excessive number of overlapping disciplines like graphic design, visual design, information design, interaction design, user interface design, user experience design, and information architecture. As plentiful as our vocabulary is for describing the layers of the software design process, for years I’ve felt like there is a fundamental design craft that is absent from the discourse. This is my first attempt to articulate it.

The output of a design process is typically tangible. Visual designers produce mockups, user experience designers produce wireframes or page flows, information designers produce taxonomies or ontologies. These outputs describe solutions to design problems. The nameless design craft I speak of produces none of these visual or textual outputs. Instead, it produces an agreed upon structure in which the designers and developers will live in as the product evolves.

To explain, I’m going to discuss the enterprise platform we built while I was in my former job as the head of product for GoodGuide. The primary purpose of the platform was for companies, commonly retailers, to assess the sustainability of their suppliers. This requires collecting information about suppliers and sharing the results with the retailers and suppliers in a clear, actionable format.

Early on in the development of the platform, we found ourselves at a fork in the road with two possible paths before us.

Both the suppliers and the retailers needed to interact with the same data set. One path was to create a single user interface to serve both their needs. Different users could have access to different functions and subsets of the data, but the overall user interface would be the same for everyone using the system.

There were reasons against this path. While the suppliers and the retailers required access to the same data, their needs and motivations had key differences. For example, suppliers needed to input lots of data and understand their scores in granular detail. The retailers, in contrast, only required read-only access and wanted to understand the strengths and weaknesses of their suppliers in broad strokes. A second path was to design separate user interfaces; one for the suppliers and one for the retailers. Each interface would reflect the distinct needs of the user group. There might be shared UI patterns across both interfaces, but the screens would be structured differently for each party.

It might be tempting to look at the choice between the two paths as a common interface design problem. Through understanding the functional requirements, you could decide which design direction best meets those requirements. Or, you could look at choice as inconsequential. A successful MVP could be built following either path.

But the decision is neither a common interface design problem nor inconsequential. The path chosen will influence the long term vitality of the product. Let’s explore the pros and cons of each direction.

Path #1: A single user interface both suppliers and retailers.

Pros:

• Future enhancements made for either party will benefit both parties. The product team won’t have to dedicate resources for applying improvements from one user interface to the other. E.g., we may create a better way to visualize score distribution with the retailer benefit in mind. This enhancement may not be at the top of the suppliers’ priorities, but they will get the new feature nonetheless. There’s potential it will be serendipitously leveraged.
• One interface instead of two allows the engineering team to be more focused. The overall application structure, one might argue, is simpler.

Cons:

• While the differences between the retailer and supplier demands on the application may look relatively minor at first, they could diverge more over time. Enhancements beneficial to one party may be detrimental to other, leading to a constrained user experience for both.
• While it may, in one sense, be simpler to have one interface instead of two, supporting the divergent needs of both user groups may lead to exploding complexity in the app. E.g. the single interface may need to be configured differently for both parties making it relatively costly to build and test new features.

Path #2: Separate user interfaces; one for suppliers and one for retailers.

Pros:

• Each interface could be designed to fit its user group like a glove. Differences between the retailers and supplier requirements could be reflected in nuanced detail.
• While the engineering team would need to build two interfaces instead of one, each of them would serve a single purpose reducing complexity from configuration logic.

Cons:

• When there is functionality that should be applied to both interfaces, UI patterns may not translate across both screens. Some features will need to be implemented differently for each screen.
• Business pressures may lead to one interface being prioritized over another. For example, if signing up and retaining retailer users is more critical to business, the suppliers’ interface may be neglected, causing issues down the road.

If you were to look at the choice as a static design problem with a fixed set of functional requirements, path #2 looks more appealing. Removing the constraint of having to design a single interface for two different types of users allows you to design the optimal user interface for each use case.

If you were to make the judgment that the needs of retailers and suppliers would continue to diverge over time, then you would have to choose path #2. But we determined that, while there were some key differences between retailer and supplier requirements, the overlapping needs across all users was sufficiently high. We chose path #1 and built one user interface with some configuration differences for retailers and suppliers. While managing the configuration complexity was a constant risk area, this direction was fruitful. The choice led to strategic advantages for us that we were unaware of upfront:

• Retailers were more important customers to acquire initially since they had the power to essentially force suppliers into the platform. Other competitive platforms had chosen to focus on meeting retailers needs at the detriment of supplier needs, leading to increasing irritation on the supplier side. Because our supplier interface was in parity with the retailer interface, we achieved a dramatically better supplier UX. Retailers, vested in the satisfaction of their supplier partners, saw this as a differentiator of our platform.
• The intent of our platform was to join retailers and suppliers in a conversation about sustainability. It was valuable that we could say to suppliers that the retailers would see exactly the same thing that they saw about their products. A single user interface for both parties removed any mystery about how the data was being used by the other side. A common user interface was conducive to a transparent and clear dialogue between suppliers and retailers.
• Constructing the interface to be highly configurable allowed us to quickly handle new use cases in the platform when they arose.

The type of design decision I’ve explored here is upstream of the static design challenges traditionally discussed. Practitioners of this nameless design craft must understand the implications of known information on the product design, but they also must anticipate how the ecosystem around the product will evolve over time. The goal is not just to identify a design problem, come up with the best solution, and move on to the next problem. Instead, the objective is to create a structure that will allow a stream of good design work to result in compounding wins. This requires design insight, but also a feel for how business and technological factors interplay with the design.

To advance our ability to understand the area of design I’ve tried to identify, I have two questions for you:

• What would you call this type of design?
• What design decisions have you made that reflect this type of thinking?

I was excited to discover that leading product thinker, Marty Cagan, referenced my article A Map of White Space for Product Managers in his post The Role of Product at Apple. Cagan’s book, Inspired, is the first thing I read that seemed to get to the essence of product management. Here’s what Cagan wrote about my article:

… a friend just recently forwarded me an article that advocated this “filling the white space” concept as the heart of the product role.  While this mindset of doing whatever it takes is admirable and something I believe is important, especially in startups, it really misses the primary point of the product role – which is to ensure that the team is actually building and delivering a product that has the necessary value.

In my post A Map of Whitespace for Product Managers, I did not intend to say that “filling white space” is the heart of the product role, so Cagan’s comments made me realize I have some clarifying to do.

I agree with Cagan that the ultimate goal of product management is to deliver value. In peeling back the layers of “value,” I describe it as creating fit between a technology, user base, and business. While creating value may be the universal objective of empowered product managers, the actual day-to-day activities of practitioners is diverse. Some product managers are neck deep in code, while others are focused on devising business models and pricing schemes. In my last job as head of product for GoodGuide, I found myself doing sales demos, customer support, and account management, on top of other core product manager responsibilities.

The specific duties of product management are so scattered that it can seem misleading to use the single term “product manager” to describe what we all do. This is why I find “filling white space” to be a useful umbrella term for describing the reality on the ground. While some product managers may be doubling as data scientists, UX designers, sales, or technical support, they’re all performing the meta-function of identifying critical gaps around the products and then rolling up their sleeves to fill the gaps. While filling white space is not the ultimate end of product management, it’s one of critical branches of activities necessary for delivering value.

As I explore in my article, A System for Designing Startup teams, companies approach the Herculean task of building a thriving business from a variety of angles. Consumer startups commonly start by focusing on creating technology-user fit in hopes of accumulating millions of eye balls, before they attempt to monetize. Enterprise startups, in contrast, often try to prove that people will pay for their service before they invest heavily in building the actual product. Each of these approaches to product building leads teams through different regions of white space.

While product managers, as Cagan articulated, strive to “discover” valuable products, they also, in the case of startups, need to discover the dedicated roles for supporting the product. This is why startups should strive to hire versatile product managers who can “prototype” job functions before the company hires a full time position. A product manager for a consumer startup may identify and fill gaps in web analytics or usability research. A product manager for an enterprise startup may double as the account manager or technical support to uncover product requirements. As the product direction becomes increasingly validated and requirements for specific roles stabilize, the company should hire full time employees dedicated to the key gaps. But having the product manager prototype missing roles in the short term prevents the cumbersome mistake of hiring a full time position before the need is sufficiently understood. I explore this concept further in my post MVPS are built by MVT (Minimum Viable Teams).

As I mentioned above, filling white space is just one branch of a product manager’s activities. The earlier stage the startup, the more this branch dominates the work load. A critical element of a startup’s transition from validation to growth is scaling job functions that the product manager and other team members were doing through hand-to-hand combat. At this stage a company becomes a bit less like a brain, and a bit more like a machine. The product manager, during this stage, stops doing UX design and data science and starts creating frameworks that allow the UX designer and the the data scientist to work effectively towards the product north star. As more dedicated roles enter the product ecosystem, tensions emerge where the product is tugged in competing directions; revenue versus user experience, user experience versus cost, short term versus long term gains, etc.. For a mature company, a product manager is less in the trenches filling white space and more in the meta-layers building rough consensus, filtering inputs, and constructing a narrative for the product direction.

While, for mature companies, a product manager’s need to fill white space recedes to the background, product managers should never be complacent that their company has designed the right organization to support their product. A product’s value may be capped by a missing role or an overly siloed supporting cast. When a gap or overly rigid structure is identified, product managers should always be in the mindset of taking matters into their own hands instead of waiting for the broader system to heal itself.