The First 90 Days for the Creative Product Manager
How to use your initial days to build and showcase Product Management skills utilizing tools from creative legends
Starting a new position inevitably comes with a lot of unknowns: what is the team like? what should I be doing? where are the bathrooms? Every role will approach these first few months differently, however I’m interested in mapping out a plan for the Product Manager. Specifically for the Product Manager who feels like they don’t fit squarely into just one of the boxes commonly used today: the Outbound Product Manager, the Project Product Manager, the Technical Product Manager, the Frontend Product Manager, the Delivery Product Manager. The Product Manager for whom I’m writing is analytical, technical, and systems-oriented, sure, but they are also imaginative, inventive, maybe a bit goofy and they may be sensitive and passionate. They display the skillset and the temperament of a Da Vinci or a Rubin or a Jobs: legendary creatives. For a while, I have been fascinated with exploring, synthesizing, and narrating how “creativity” can be claimed in the field of Product Management. I have taken to calling this role the “Creative Product Manager”. In this blog, I explore how Creative Product Managers can set ourselves up for success when starting with a new company specifically looking at the first 90 days. I define what areas the Creative Product Manager should focus on, what tools can be adapted from the traditionally creative world for us to leverage, and what we can deliver within this initial time frame to build a strong foundation.
Product strategy
In their essay Find Innovation Where You Least Expect It, entrepreneurs Tony McCaffrey and Jim Pearson diagnose that creativity in businesses are often inhibited by cognitive biases: functional fixedness, design fixation, and goal fixedness. They’re prescription for overcoming functional fixedness is a “generic parts technique” where an object is broken apart into its elements and each element is then broken down further until they’re described in their most general terms. McCaffrey and Pearson use a candle as an example which when broken down fully is comprised of long, interwoven, fibrous strands and cylindrically shaped lipids. By deconstructing an object to identify its core components, we enable more use cases, i.e. ideas, to be discovered. This discovery results from a manifestation of creativity that Einstein described as “combinatorial play”. In Creativity Under the Gun, founder Constance N. Hadley and fellow authors illustrate this form of play as “throwing a bunch of balls into the cognitive space [and] juggling them around until they collide in interesting ways.” The theory being that ideas that are rarely combined produce more novel outputs, and, as we know, creativity is partially about generating novel ideas.
Applying this concept to product, the Creative Product Manager seeks to generate novel products that are useful. This requires us to break apart our resources into their elemental parts. The analytical equivalent of “parts” in product strategy terms would be “strengths”. By identifying strengths early on, we set a foundation for combinatorial play to recombine these strengths in interesting ways to create new products. In addition to identifying strengths, Adam Brandenburger suggests in his article Strategy Needs Creativity to “look at how weaknesses could be turned to the company’s advantage.” He gives the example of Tesla which does not have the dealership network utilized by most car manufacturers. While this can be viewed as a weakness, Tesla found an opportunity to innovate by taking control over pricing which eliminates price variations found in the traditional dealership model.
Some suggestions to identify strengths and weaknesses:
- Use your products — spend 2 hours a day during your first two weeks just using your product: figure out how they work, figure out the technical architecture
- Interview your elders — have 3 coffee chats a week during your first month starting with the people who have been at the company longest: learn the company lore, find out how they keep up to speed on the industry, ask them about what they’re working on and how they’ve approached the problem
- Explore other products in your industry — spend 2 hours a day during your first two weeks researching other players in your industry and what they are building
Performing this analysis will result in identifying strengths and weaknesses and will also inevitably lead to identifying opportunities to utilize the strengths in your industry as well as threats exposed by your weaknesses. Documenting these will result in a full SWOT analysis for our new company, an artifact that will be core to our role as Product Managers but also as a creative foundation.
Stakeholder management
Some of the resources that we will discover through our SWOT analysis will be the people with which we interact, e.g. coworkers, customers, and partners. Many of these individuals will come into play during one of our projects. They might be actively involved in the project, be able mobilize resources to affect its outcome in some way, or have an interest in the project as they are positively or negatively affected as a result of its execution or completion. In the parlance of product management these individuals are stakeholders and our interactions with them utilize various skills under the area of stakeholder management. Within our first 90 days, it is important to start building relationships with these stakeholders and to understand how to work together. I’ve been working on a diagram to capture this analysis that I will refer to as a stakeholder diagram which I discuss in more depth in a different blog:
- Core: This ring of stakeholders usually contains your product team including the Engineering Manager who mobilizes the technical team and the Designer who produces mockups, user flows, and the ultimate design. Most decisions on the project require a thumbs up from these stakeholders.
- Contributors: Stakeholders in this ring include individuals who either contribute to your project or are directly affected by your project. You want to make sure that stakeholders in this ring are aware of your project and you have captured their feedback early. However day-to-day or week-to-week decisions do not require their input.
- Observers: These stakeholders are mostly unaffected by your project and will have little or no input during the process. Many of them just want updates on what the project is and when it will be released. While their feedback could contain insight, decisions should not hang on their input.
- Evaluators: I adapted this idea from Ed Catmull, co-founder of Pixar and former President of Walt Disney Animation Studios, who discusses in his article How Pixar Fosters Collective Creativity the “creative brain trust”. The idea is to form a community of stakeholders within the company who have minimal investment in the product and no authority over the outcome but a mastery of value capture. The purpose of this ring is to have a sounding board when you are struggling with the value proposition for a feature or product which is a determining factor during the prioritization phase of the product development process.
The further out an individual is in the stakeholder diagram, the fewer touchpoints you should need with them. The goal is white-glove service for the Core and self-service for the Observers. I’ve found that keeping an updated roadmap should be sufficient to answer 90% of the questions of an Observer.
In the first 90 days, take a moment after your coffee chats to reflect on the discussion and pin the colleague in the ring of the stakeholder diagram where you believe they fit, for now. For example, this person is working on something that reminded me of one of my focus areas — pin them as a Contributor. That person had key insights and I left the conversation trusting their opinion, but they’re so far removed I doubt I’ll organically interact with them often — pin them as an Evaluator. This person keeps asking for roadmap updates and for specific release dates for features — pin them as an Observer. Individuals will shift between rings over time so think of these as initial positions. The goal after 90 days is to have a quorum of individuals in each ring to visualize interactions with this individual thereby removing the cognitive friction of figuring out who to go to during product development.
At this early stage, it’s also helpful to start discussing expectations particularly amongst your Core stakeholders. In the first 90 days, it’s important to understand how these team members work. To prepare for these discussions, list out the details of how you’ve moved through the produce development process in the past. Who was responsible for user research? Where was key information about the project captured? How were specifications defined and who was responsible for which artifacts? What was the hierarchy or tickets and how was responsible for each tier? Now ask the team about their process and list out the responses. The goal is not to change anything. We haven’t yet built the trust or the capital to do so. But to get anything done we need to understand how the team works, and, once we’ve gone through the existing process a few times then can start making suggestions as to any weaknesses we’ve observed and how portions of alternative processes that we’ve observed might strengthen those areas.
Product development
Some timeless advice from Michael Watkins in his book The First 90 Days is to secure “early wins”. Watkins elaborates that an early win should be “based on the expectations for your position and as laid out in prior conversations with your boss and stakeholders”. Having spent our initial days holding these conversations, we aligned on these expectations, started to build relationships, and formed an understanding of their needs. Now we need to identify what will be our early win. We want this problem to be important and able to be delivered in this 90 day period. A good starting point is to notice patterns in what our stakeholders consider a problem and acknowledge needs fixing. Look for unfinished projects that are followed by “we just haven’t had the time”. Given our limited timeline, we’ll need to promptly assess what skills, which team members, and how much time are necessary to execute on this. A good target for an early win is a problem where the details have largely been fleshed out already. If there are minimal details then it’s probably not an early win or a problem that needs solving at this time. The ideal early win can be done quickly with a small team. Remember that we filtered for problems that people just haven’t had the time to solve meaning that all the project really needs is someone to dedicated to making it happen. Once you’ve identified that win, take action: execute!
Securing an early win, in the parlance of product management, will exercise your product development skills and gain critical trust within the company. The first phase of product development is discovery where the problem is explored and clearly defined. If the problem has not already been solved then there is a good chance that the problem was not clearly defined or that it has not been thoroughly reduced to a core issue. In product management parlance, to express a problem in an action-oriented manner we use goal setting, a skill within the area of product development. For goal setting, the Creative Product Manager also has an arsenal of creative tools to deploy. Returning to McCaffrey and Pearson, stating a goal typically follows the format of verb (improve) + noun (usage) + prepositional phrase (of the API). They recommend “playing with the hyponyms of each of its parts [to] explore diverse approaches to your problem in a simple and cost-effective way” where hyponym is referring to more-specific synonyms, e.g. clamp is a hyponym for fasten. For example, if we substitute increase for improve such that our goal becomes “increase usage of the API” have we made the goal more explicit and provided additional clarity on what we want to accomplish? Here too we can lean on the SWOT analysis that we have been working on and leverage our increasing knowledge of the product to further reduce the goal. For example, let’s say that we learned that usage of the API requires holding an API key; we can state the goal now as “increase the number of keys for the API.” This might make discovery easier because now we have something more specific to explore. Perhaps we discover that the number API keys are low because users simply don’t know where to generate one. Your early win can be a simple redesign to make the flow easier.
Rick Rubin utilized this tool in an interesting way while working on a record with legendary musician Tom Petty. They found boxes of refrigerator magnets of words, removed the connector words (e.g. the, and), and attached the rest to a music stand. Petty then started to sing while randomly choosing words from the music stand. After many iterations, these eventually became the lyrics for his tracks. Through replacing and rearranging words, an album was created.
In addition to playing with the components of the goal, McCaffrey and Pearson introduce a second creative tool that can be useful for Product Managers: brainswarming (a play on words of the standard brainstorming exercise). The exercise splits problem solving into goals and resources and then connects resources to goals via applications of the resource to achieve the goal; this forms a graph. The authors use the Titanic as an example and recommend starting with the most obvious solution connecting a goal node “Save passengers” to a resource node “Lifeboats” via an application node titled “Put people in lifeboats.” The exercise progresses with participants contributing new goals or new applications which in turn spurns identification of new resources. The result of brainswarming will be a list of potential solutions derived from a common goal and based on available resources.
Brainswarming involves both a knowledge of the goal to be achieved and the available resources (i.e. strengths) of the company both of which we have uncovered through our SWOT analysis. One method of contributing new goals is to rephrase and reduce the root goal. This is where we can apply the hyponym goal setting technique from above. Additionally, McCaffrey and Pearson point out that the people involved in the exercise typically will fall into two camps, “strategically oriented people can focus on refining the goal, while those more familiar with technologies and production processes can begin with the resources.” Again, our initial stakeholder management work from our initial days will help to identify who falls into which camp to ensure the right mix of perspectives are present.
In product development, the discovery phase is followed by a prioritization phase, an execution phase, a promotional phase, and a retrospection phase. Since we are trying to secure an early win, our focus should be on completing the execution phase within the first 90 days. The output of discovery is a list of potential solutions, therefore the goal of prioritization is to reduce this list to solutions that will address the goal and to order the reduced list by impact and expense. This will create a roadmap. This roadmapping process can be daunting especially for those of us perfectionists who feel the need to find the optimal solution. A concept that I’ve found helpful is “satisfice”. I’m reminded of a quote by renowned record producer Rick Rubin, “There is no connection between how long something takes and how good it is. but that also doesn’t mean that it will be good quickly.” What you prioritize will probably not be the optimal solution, i.e. the perfect, final idea that will forever solve the problem. The satisficed goal during execution should follow the Pareto principle where the first solutions in our roadmap have been evaluated for impact, i.e. they address the key causes of the bulk of the issues, and expense, i.e. the duration and effort needed to deliver. Early wins should maximize impact with an expense that doesn’t exceed our 90 day window. The ideal product team is working iteratively and is open to experimentation. Releases should be viewed as experiments that gauge how much impact our hypothetical solution actually has on our stated goal in the real world. Therefore these first releases should be small and flexible.
The output of the prioritization phase is a reduced list of solutions in priority order, therefore the goal of the execution phase is to pop the first item off the list and deliver it. The deliverable for the Product Manager, creative or not, is some sort of specification communicating to the product team what is to be delivered, i.e. a product requirements document (PRD). Once communicated to the team, there will be back and forth about the details of what’s being asked for and specifics like edge cases. This is where the Product Manager must ensure alignment with the goal while remaining flexible to feedback and willingness to scope the request down further. There are times when this pre-execution process of getting everyone to understand what is being built, receiving and integrating feedback, and waiting for your team members to produce their deliverables can drag on in what would be an amusing observance of Parkinson’s law, “Work complicates to fill the available time” if the product of that work wasn’t expected from you. This is why Product Managers often leverage constraints. I’ll discuss constraints more in future blogs, but generally the constraints in a Product Manager’s control are time and scope. In this case, we have a time-based constraint: we want to deliver something in 90 days net however long we used for discovery, prioritization, and the bit of buffer we reserved for initial product strategy and stakeholder management. We have kept this in mind during the previous phases so the first item in our prioritized roadmap should be something that we reasonably expected to fit this time frame. As a general purpose rule, I’d quantify this time frame as 60 days given:
90 total days — 15 days buffer + 10 days for discovery + 5 days for prioritization = 60 days for execution
So in pre-execution, we’ve further refined the PRD until the product team collectively estimates 60 days out from the start of the execution phase as time the delivered date. While the team is executing, we are making ourselves available to the team for the inevitable questions and additional refinement that occur when actual work is started. Having flexed our product development skills, we shift focus back to work on honing our product strategy skills through development of our SWOT analysis and our stakeholder management skills through adding to our stakeholder diagram.
Wrapping it up
Product Management is one of the most cross-functional roles at a company. Product Managers are expected to have expertise in the areas of product strategy, stakeholder management, product development, and a dozen more. We must decide which areas and which skills nested within these areas to develop and in what order. I argue that the Creative Product Manager spend their first 90 days focused on developing product strategy using creative tools like functional fixedness and combinatorial play to guide their development and set a strong foundation for further creative development. In addition, building skills in stakeholder management using frameworks like Pixar’s collective brain trust to create a group of individuals to turn to when you need help answering one of the most important questions for the Product Manager to answer: does this have value? And finally developing the area of product development using tools like hyponym goal setting, brainswarming, and satisficing to execute an early win. Thus, the first 90 days for a Creative Product Manager could look something like this:
This 90 day plan enables the Creative Product Manager to structure the critical early days at a new company. Following this, we build career capital within the field of Product Management utilizing creative tools that leverage our unique, creative side. We execute deliverables that showcase this effort and build trust with our colleagues. This lays a creative foundation on which we can build novel products that are useful.
Originally published on Mirror — https://mirror.xyz/0x6c26EB64D7f2645E466b019105aCD1C51aa67fb8/5aH8-tCRSIq3hzSmZZWd5UOfeDpnUzWTzZKuUFj2v78
