Recently, the US Department of State decided that they needed to change their official publication font from Times New Roman to Calibri. This set off quite a firestorm in a very small community that cares deeply about the impact of fonts on accessibility and tradition.

Anyone that has done some research on fonts knows they can be powerful in what they communicate, how functional they can be, and what emotions they might impart to your readers. The choice of Calibri is intended to make government documents more accessible, especially when combined with a standard 14pt size.

This is the type of detail that designers and product managers need to think about when building great products. Font selection impacts usability, tone, and brand.

Fairwords New Design

In late 2021, we were in the process of designing a new foundation for our product portfolio. This was going to be a major architectural lift but it was also a significant redesign of the user experience that many employees at our customers would experience. I wanted to take a very deliberate approach to font selection and tone in our products.

I have built many products but font selection rarely made its way to the top of the priority list. This time would be different. Font, microcopy, and color — everything was going to be designed with intention.

After narrowing down our font selection based on a variety of objective and subjective rationale we felt we had the perfect font — Avenir. Highly readable, sans, and could allow a high density of content without feel heavy. I loved it.

In parallel our marketing team was leading us through a company rebranding that, surprise, also involved fonts, colors, logos, and copy tone. On the short list for fonts was something that look familiar. It was Avenir!

As a team that was trying to make all the right, deliberate decisions, we wanted our applications and marketing brand to be complementary. It creates a more consistent story and brand for users.

The decision was now very easy — we would use Avenir as our primary font.

Wait. Something is not right

Fast forward a few weeks as we were fast approaching a first milestone release to the market and we discovered a problem. For some reason our app was not rendering as nicely across Windows and Mac.

I actually noticed this for a little while but my primary computer is a Mac. On Mac, our application was looking gorgeous (IMHO). Yet, on Windows, the screens just looked off. Some text was blurred and bleeding over borders. Screenshots for marketing materials looked funky when done on Windows PCs.

It turns out, Avenir is not installed on Windows by default. Therefore, our application was falling back to alternate sans fonts. Some more research determined we could pay to license the font and then we would have to “ship” the font to ensure our application looked equally great everywhere.

What to do?

After understanding the situation fully, with just a few days before launch, we had to decide on licensing the font or switching fonts altogether. Mind you marketing already progressed heavily with our decision.

We started to hunt for alternatives and found there was nothing that was a near perfect replacement. There are many design posts and expert lists that recommend alternatives but those opinions generally differed. They differed because nothing was a good as Avenir.

On the flip side, licensing and delivering our preferred font, did not appear to be commercially viable for us. I possibly could have accepted the cost, but with a goal of producing a product with really good unit economics means not piling on incremental costs unless they could later be replaced or were critical to delivery.

Time for Pragmatism

As I said, for Fairwords new platform, we wanted to do things right. However, doing things right has many dimensions that need to be considered. In this case, adding cost could not be justified against the benefit of a superior experience.

Furthermore, while we could have easily started with Avenir and then switched later, we did not want to initially launch knowing we would have to change it later. This would disrupt the experience of all our users and brand identity.

We had to take the fastest, most pragmatic approach and chose an alternative that best met our original selection criteria — plus work flawlessly across operating environments.

What’s more, we decided to break the consistency in design with marketing. These decisions were painful. We had sunk cost and grown to love the look Avenir enabled.

Our engineering team made the switch in minutes. It did take a bit longer to QA it, given this was not something that could be automated.

Just like that, Avenir was gone from the product.

Lessons

Months later, no customers have said anything about our fonts. Really, users don’t tend to comment about things like that unless they are really bad. Our marketing materials look great in Avenir — even with a healthy dose of product screenshots not in the same font.

The decision to go with Avenir or an alternative would probably not have had a significant impact on top line revenue or UX. It is easy to want to do so much right and get lost in the fact that doing every individual thing right is not actually the goal. The goal is doing the WHOLE thing right, or as best we can.

One more thing, in case you were wondering. The font we finally settled on… Lato. Not bad, if I say so myself. (Even on Windows)

I only learned about Design Systems in the last several years. No software company I have worked at used them. So what is a Design System?

According to the nn/Group:

A design system is a set of standards to manage design at scale by reducing redundancy while creating a shared language and visual consistency across different pages and channels.

At Fairwords and many small startups, Design is part of the “Product” function because it is a core part of identifying opportunities and bringing solutions to life. So as I ramped up Design practices within our company our lead Product Designer pushed for implementing a proper design system.

“It is best practice for modern tech companies,” he said, “and it will be a good investment in our future.”

Should we implement a Design System?

I like best practices. Why reinvent a process or solution to a problem that thousands of industry experts have already decided is the answer?

Well, in this case, I decided that we would not specifically set out to build a Design System. As a startup — that is still searching for product/market-fit and a sustainable business model — we do not have everything figured out yet. If we did, I would stop calling us a startup.

Design Systems are about managing design at scale. This means keeping design consistent and efficient across multiple product teams.

Just like you should not attempt to scale your sales function until you figure out product/market-fit, you should not need to scale your design team early either. If your design team is currently only 1-3 people, then this investment you are making to scale the function is primarily for future benefits.

Whenever you are weighing an investment today for future benefit, we must ask ourselves these basic questions:

1. Is this the most important thing we can be investing in right now?

2. Is a Design System going to help you find product/market-fit faster?

3. Is a Design System going to help reduce viability, feasibility, or usability risk?

For us the answer is no to all of the above. Investing in a Design System, assumes you are at a point where you are scaling teams to execute faster and more consistently. It assumes you are growing product assets significantly and want to minimize the future cost of change through better design components.

How to design without a Design System?

I keep referring to investing in a Design System. Investing is the key term to me. The wrong decision here, for most, is to make a significant upfront investment in a system. Decide on the right tools and build out a library of components that will fit every conceivable use case.

The better, more agile approach, is to build components as you need them. Yes, at times you will need to go back and adjust existing components but that is OK.

Working in this manner, you can still create a consistent and, dare I say, great user experience. Your advantage here is having a small team that works closely together. Tight feedback loops and cross functional collaboration are what drives better design.

You do not know your users today like you will know them tomorrow. Imagine that today you have a hundred users (or none) and you hope to have tens of thousands in a few years. What are the odds that the users you have now will match those you wish to attract and retain in the future?

Similarly, today you have 1-2 designers working with 1-3 product teams. What are the odds that the decisions you make today to make them scalable and usable will be the best decisions for 10 designers working with 100 engineers?

Waste. Waste. Waste.

All of these decisions needed to be made up-front to build out a Design System will amount to waste. Don’t do it. I don’t care what Brad Frost says.

Startups need to focus on today’s riskiest problems first. This is an existential necessity. Problems scaling design is a nice problem to have because that means you have grown.

When that becomes the most limiting factor in your business, congratulations, you are no longer a startup.

Skip the Background. Take me to the Nuts and Bolts.

Background

Before digging into one way we are making use of generative AI, it is important to first understand the context. Fairwords is a small startup who primarily focuses on regulated markets. We develop, market, and sell two main products - Guide and Archive - both require sophisticated analytics to detect risk in what we write but they have starkly different operating requirements.

The Archive is how regulated businesses, like Financial Services Organizations, retain messages sent by covered employees and fulfill their legal obligation to identify fraud, market abuse, corrupt practices and other risks. Archive analytics runs on streaming messages or periodic batch processes depending on source service.

While Guide uses real-time analytics to let users know before they hit send that they may want to modify their language. This is our uniquely differentiated capability to supercharge compliance by preventing noise from ever hitting the Archive caused by innocuous messages.

Both these services are enabled by consistent detection capabilities. For the Archive and communications monitoring space generally, the state of the market is to use deterministic rules to find strings of text known to be related to different types of risk.

For example, if an energy trader writes an IM to a colleague, “I plan to manipulate the price of brent today” the business is supposed to notice. It should be not only discoverable in the retained messages but they should have tools and processes in place to help them detect such a risky message.

I plan to manipulate the price of brent today

Basic Detection Challenge

To detect such language the software may look for the specific phrase “manipulate the price”. Since that may be too specific, the users may configure it to look for the simple term manipulate to ensure they do not miss similar phrases. Unfortunately, most leading communications monitoring tools will stop at this point giving users the option of an overly specific phrase or a simple one that generates lots of false positives.

The ultimate solution to effectively balance these trade-offs is AI. A mathematical model can be trained to understand the context of the term manipulate such that it is only flagged in a negative context.

Examples of manipulate in context:

• I plan to manipulate the spot price of brent today ❎ Flag

• I am going to have my spine manipulated today ✅ Ok

• She asked me to manipulate the audit record ❎ Flag

• Data engineers mostly just manipulate data ✅ Ok

The problem with developing such an AI model lies in the training data. An analytic model can only be as good as the data used to train it. In order to teach the model to classify phrases that are ok versus not ok, you need lots of examples of both.

The primary approach to developing good training data is to find a large corpus of domain relevant data. Then use humans to go through a random sample labelling it as manipulation risk or not manipulation risk.

In the real world most conversations will not include anything having to do with market or price manipulation. So you may find <0.1% of phrases with something that is worth labeling as manipulation risk. Further, to get a meaningful set of language that conceivably resembles manipulation risk might takes millions of records and, even then, some obvious phrases might never have been seen in the data.

The second problem is, gaining access to such large amounts of sensitive workplace communications for the purpose of training a model can be difficult. Snippets are sometimes in the public domain when illegal activity is found but it is too sparse to be meaningful on its own.

It turns out that, beyond market manipulation, a lot of the particular risks that compliance might be concerned with are associated with the same training data challenges.

Mitigating Risk with Generative AI

Generative AI is a highly scalable NLP solution for generating human like data that can be then used to train separate detection models. Yes, I know you may ask yourself, if we don’t have data to train detection models appropriately then how can we train generative AI models?

While generative AI has been around since the 1950’s it is only very recently that large language models like GPT-3 (Generative Pre-Trained Transformer 3) have begun to generate human like text and become reasonably available to the general public. It is the massive scale of that enables it to generate new content from few examples

The availability of LLMs like GPT-3 remove the need for individual researchers to:

• Develop the mathematical algorithms

• Source massive amounts of data

• Label massive amounts of data

• Run the compute infrastructure necessary to produce the models

Some examples to illustrate these benefits:

We can see that GPT-3 has been built at a scale that is out of reach for the vast majority of hobbyists up to large corporations. Collecting and processing 500 billion tokens (eg words) with 175 billion parameters required ~2500 Petaflop/s-days to train.

Needless to say these are ridiculous numbers and require levels of investment not possible at Fairwords. Luckily, we don’t need to do it. These models and alternatives are now available as open source models (e.g. Bloom) and paid API services (e.g. OpenAI) removing the huge initial investment hurdle.

Nuts and Bolts

Given all the benefits of these new Generative AI models, Fairwords is able to use these models to quickly generate high quality human like conversation data relevant to our domain with minimal input.

While we have built tools for building such synthetic training data, the process is straightforward.

1. Provide sample input prompts into the selected model.

2. Review results.

3. Re-input those results iteratively to generate conversation flow.

4. Repeat steps 1 - 3 to produce many conversation variations being careful to widely vary the starting prompts for generated output diversity.

Once we have raw conversation data we can (optionally) co-mingle it with non synthetic conversation data and go through a data labelling process - in house or via third party services.

After producing training data in the 2,000 to 10,000 record length we can train our detection model. We then test the performance of the detection model against precision and recall goals we set - just like we would for non-synthetic data.

The end result is that we can detect all sorts of specific compliance risk in conversations that rarely happen in workplace conversations. This enables us to strike the ideal of both increasing our ability to find risky conversations (recall) AND minimize the rate of false positives (precision) that waste compliance time.

I share this as an example of how we are using new Generative AI capabilities in the market today. It takes a long time to develop the institutional capacity to effectively leverage data science. As Product Leaders, it is our job to ensure we are laying the groundwork to take advantage of these technological innovations.

Hopefully, this article plants a seed of ideas for how Generative AI can help you deliver on your roadmap goals.

Final note. While I do my best to understand the benefits and application of these technologies, I am definitely not “the” expert at Fairwords. I work with some great data scientists who actually know what they are doing (and try to teach me). If you want to connect to learn more just comment on this article or DM me over on Twitter.

Share

Welcome to the first edition of the ProductFix newsletter in over a year. What the heck happened? In short, I got too busy to keep this up. Writing a newsletter is real work that takes time and energy. I do it because it helps me organize my thoughts and give back to the community at the same time.

Now I am back. My day (and night) job as VP of Product @ Fairwords will continue to take the majority of my cognitive energy. So I have decided that the best way to talk about product management is through leveraging the work I already do in my day job.

I can’t promise to write on a weekly basis. However, when I do write, I will share real-life activities, thinking, decision-making, and struggles that come with product leadership in my startup. With luck, this will be helpful to learn from, entertaining, or both.

If you keep with me here, I will share a lot of what we do, how we do it, and what we hope to accomplish. Be warned. A lot of it is messy.

Here are some highlights about Fairwords to get this new journey started right:

• Fairwords is a regtech B2B SaaS business, HQ in Denver but now fully remote

• We are a small and nimble product development team with a mix of FTE and contract employees spread out around the world

• Our core solutions include desktop software, a slack app, and a variety of customer-facing APIs to connect with our AWS cloud-based service

• We do a lot of integration work with various business messaging technologies like Teams, Slack, WhatsApp, Bloomberg IM, Email, SMS, Skype, etc.

• Various forms of AI are sprinkled throughout our solutions in both visible and invisible ways to help our users

Details Details Details

If there are questions or topics you want me to specifically cover then comment on this article or message me a message on Twitter.

Topics I plan to cover:

• Startup 0-1, when some people already think you are at 1.

• Organization design

• Health and unhealthy conflict with Engineering

• When to Invest in tools to help teams scale

• Build vs. Buy decisions

• Coping with the desire to go after the nice shiny new object

• Building things that take a long time in a world that needs results now

• Why Product-Led Growth didn’t work for us

• How I think about competition

In the Next Newsletter

Everyone is talking about generative AI. At least, it seems they are but maybe OpenAI is automatically generating a lot of Tweets and articles with GPT-3. It is really hard to tell but in my next article, I will share a very practical way we are using generative AI today in my business.

If you know others that would benefit from these stories then please share my newsletter. It is the best way to show I am writing about the right things.

Share ProductFix

For now, I will leave you with the article I could have published… if I was lazy and just used ChatGPT to write it for you.

ProductFix News via ChatGPT

Dear fellow product managers,

As you know, the field of product management is constantly evolving and adapting to new technologies and trends. One area that has seen significant growth and development in recent years is the use of artificial intelligence (AI) and machine learning (ML) in product development and management.

In this newsletter, we'll explore the various ways that AI and ML are being used in product management, as well as the potential benefits and challenges of implementing these technologies in your organization. We'll also discuss the skills and knowledge that product managers need to stay ahead of the curve in this rapidly-evolving field.

But first, let's take a step back and define what we mean by AI and ML. In simple terms, AI refers to the ability of a computer or machine to perform tasks that typically require human intelligence, such as recognizing patterns, learning from data, and making decisions. ML, on the other hand, is a subset of AI that involves the use of algorithms and statistical models to enable a computer or machine to learn from data and improve its performance on a specific task over time.

So, how are these technologies being used in product management? Here are a few examples:

• Automating routine tasks: AI and ML can be used to automate routine tasks in product management, such as data collection and analysis, market research, and customer feedback analysis. For example, Salesforce's Einstein AI platform allows product managers to automatically analyze customer feedback and identify common themes and trends. This can save time and resources and allow product managers to focus on more strategic and creative tasks.

• Enhancing decision-making: AI and ML can be used to process and analyze large amounts of data to inform product strategy and decision-making. For example, Amplify's AI-powered product management platform uses natural language processing and machine learning algorithms to help product managers understand customer sentiment and identify key insights and opportunities. This can help product managers make more informed decisions about product features, pricing, and marketing.

• Improving customer experience: AI and ML can be used to personalize and improve the customer experience. For example, eBay's AI-powered recommendation engine uses machine learning algorithms to generate personalized product suggestions for each individual customer. This can help customers discover new products and services that are tailored to their individual needs and interests, leading to a better overall experience.

While the potential benefits of AI and ML in product management are clear, there are also challenges and considerations to keep in mind. For example, implementing AI and ML technologies often requires significant investment in terms of time, resources, and expertise. Additionally, there are ethical and privacy concerns around the use of these technologies, and product managers need to be aware of and comply with relevant laws and regulations.

In terms of skills and knowledge, product managers who want to stay ahead of the curve in this field will need to be familiar with the latest trends and developments in AI and ML. This may involve attending conferences and workshops, such as the AI Product Management Summit, reading industry publications, such as the Product Management Today newsletter, and networking with other product managers and AI/ML experts. Additionally, product managers who are able to apply AI and ML techniques to their own work, such as using data analytics to inform product strategy and decision-making, will be well-positioned to take advantage of the opportunities presented by these technologies.

In conclusion, the use of AI and ML in product management is an exciting and rapidly-evolving field with many potential benefits and challenges. As product managers, it's important to stay up-to-date on the latest developments in this area and to be prepared to apply these technologies to your own work in order to stay ahead of the curve.

Best regards,

Sean Sullivan

Subscribe now

You have demonstrated many years of success in Product Management roles at established enterprise businesses. Perhaps you have worked your way to Group PM, Director, or maybe even VP Product within a large bureaucratic enterprise. Now you have the startup itch.

After a number of interesting discussions, then some informal and formal interviews, you are now staring at an offer to join StartupCo.

Awesome! Congratulations!

Wait. What are you getting yourself into? You have bills to pay? What do you know about this company?

First the Backdrop

Joining a startup can be a dream and a nightmare at once. If your professional career never involved a startup, or not in a long time, then you have lots of questions that you should be asking yourself and the company before you take the plunge.

This article is about some of the questions, from my personal experience, that are really significant to ask. The specific emphasis here is on experienced PMs that have an opportunity to join an early stage to growth stage startup as their product leader.

Why do you want to join a startup?

For many that are in large organizations, you may have huge responsibilities already. Your products may be used by hundreds or thousands of customers. You may have a team of people reporting to you and many more directly impacted by your leadership.

Is the desire to go to a startup to learn? Is it to get more responsibility? A VP or CPO title? Is it to get your hands dirty in the trenches working with customers directly again if you are now 3 steps removed from them?

The main thing is to understand why you want to make the move and use that as the context for how you ask questions and analyze all the other data you collect.

Would you invest in this startup?

If you were an investor considering funding this business, would you do it? What kind of questions would you ask.

If you are getting an opportunity to join a startup with 10-50 employees as the head of product, it means that the company has determined they are missing a key leadership position. So they are deciding that filling this is strategic for them to be successful.

On your side, you need to assess if this is worthy of investing your time. Most startups fail. Your compensation will be less generous except for the equity piece. That makes you a potential investor in addition to a key part of the executive team.

You should ask questions about the business model and finances. If they do not want to share this info with you, how can you make an investment decision?

Once you have it, what do you think? Do they have a strong premise? Is the business strategy sound? Where it is lacking do you want to be a part of finding solutions?

Key to me here is the problem they are working to solve. Is it big and have they validated it? Do they understand the assumptions that underpin what they are doing.

Do they set goals and measure progress? Do they minimize the number of plates they are spinning at once?

Remember that a startup is an organization seeking a profitable business model. So do not expect perfection here. Expect a work in progress.

What do you think of the people and culture?

Don’t think for a minute that politics do not exist in a 15 person startup. In fact, they can be more toxic here than in a 3,000 person enterprise and they are unavoidable. So meet with as many of the people you will be working with and assess how they will be to work with.

Are the execs focused on solving the big problems or on who does what? Are titles a big thing to them or do they not even know the official titles of everyone? What kind of communications and meeting culture do they have? Especially, with work from home / remote heavy startups, do they value bringing the team together periodically? How do they talk about one another?

Look for signs of excessive turnover. Turnover can be high in a startup, especially in sales roles or if they leverage contract employees. Yet, when the team is on to something, and incentives are aligned, everyone wants to stay on-board the ship. So a red flag would be significant people leaving on their own.

When meeting with the team, I want to see a group filled with ideas of where the company could go. Lot’s of people asking questions and being curious about how they can do product management better and anything else. Look for team players that are open to discuss their functions and not get defensive or protective when you ask about them.

Startups are about a group of people all doing continuous discovery work to learn. It demands inquisitiveness, open minds, and desire to always improve.

Is there a Product Team?

Most smaller startups you join will have everyone focused on a single product or suite of closely related products. Some larger startups might a a few such teams.

How do they structure product teams? Do they consider engineering and product management to be the same team? Do they have reasonable ratios of design, engineering, product management, and other roles? They probably don’t. It should be part of your job to get them there.

Do they use a lot of external agencies, contractors, or favor getting everyone on-board as an FTE?

What does the software development process look like?

This is critical to understand for a head of product, and you can certainly institute or drive change to better process models — however, knowing the as-is state, is a must starting point.

Key to understanding this is who leads engineering (e.g. CTO, VP Eng) and what is their relationship with you, as the head of product? Some organizations may also have a senior design role, what is their relationship?

When you step in the org, the existing leadership has presumably built some team and processes that they have a vested interest in. How open are they for improving what exists today?

Are there any existing PMs (or POs)? There is a good chance they do not exist and you could be the first product leader coming in from the outside. You will be shaping the teams view on what the head of product should be doing.

Does the team expect some singular expert to assign task work or do they subscribe to the autonomous team concept? Are they flexible on their development methodology or do you have a group of methodology purists? If they are a scrum shop, they may want you to step in immediately playing the PO role. Are you ready for that?

Finally, many times that VP Engineering person, who may also be a co-founder, is going to be an absolutely critical partner to you. You will have tons of product, process, customer issues, and people challenges to solve in the future. Is this someone you think you can work closely and productively with?

What about the Product?

As a product management hire, frequently people dive immediately into the product. Frankly, especially in a startup, the current product you are inheriting does not matter that much. Without a doubt it will be less mature, more debt ridden, and not as sophisticated a solution as you have been told.

This is all fine, your job is not to maintain this existing product but help the company build something far superior at solving valuable problems for 100x the number of existing customers.

By all means, get demos, review the architecture, learn the challenges, get access to customer feedback, etc. Just take this with a grain of salt. It is a starting point only.

Why you?

Are you the first candidate they talked to about this role or the 100th? Why do they thing you are right for the job? Do you see the same thing?

Did anyone have this job before? If not, who in the company handled the responsibilities that will be placed on your lap?

Who will you be reporting to? If it is a startup B2B product company this will tell you the organizational mindset. Are they going after a traditional enterprise sales process or building for product-led growth?

Before signing up, be sure to ask the CEO and your peers what success will look like in 30-60 days and how they think you can help the team achieve that?

If you can handle the risk, take the opportunity.

At the end of the day, there are no right or wrong answers to the questions I laid out above. I have views on what I prefer but you may have different preferences.

The key is that coming into a small startup as the VP Product, will give you every opportunity to help change the answers to the questions above as you see fit. You are coming in not to drive stability to help the organization and product evolve toward great success.

You will be surprised by a great many things when you join any new company. For startups there is usually so little process maturity company to your BigCo job it could be shocking. However, this lack of maturity actually enables much of the responsiveness and innovation that make startups such an enjoyable ride.

Finally, do you take the job?

I covered a number of useful questions you should be exploring. I specifically stayed away from the compensation questions. However, you clearly cannot. Be sure that you are comfortable with the risk-reward opportunity. This is another full topic I may explore later.

With that said, I have two closing comments:

1. Take as much equity as you can. If you believe in the investment, commit to it. Often you will have some negotiating power around the mix of salary vs. equity. Max the equity piece as long as you can live on the salary component.

2. If this fails, you became an experienced startup VP Product. There is huge demand for this experience. Whatever you learn will be hugely valuable on the next ride.

Headline May 26, 2021:Jeff Bezos to formally step down as Amazon CEO on July 5, Andy Jassy to take over

There is no doubt that Jeff Bezos has built a remarkable business in Amazon. As he steps down from the role of CEO, it is worth asking if it will endure when he is no longer at the helm?

We can debate whether he will still be driving things as the Exec Chairman of Amazon’s board and to whats degree. However, at some point he will be less involved.

So it is both interesting to look at how the company got here and if it has been built-to-last. As an investor, competitor, partner, customer, or business person looking to adopt best practices - it pays to analyze such a remarkable case.

Working Backwards

I am a customer, small retail investor, and product manager who has followed Amazon for many years. I have never worked there. Nor have I met Mr Bezos. Lucky for me (and you), an excellent behind the scenes book called Working Backwards by Colin Bryar and Bill Carr recently shed light on how the sausage gets made.

This book is the basis for much of my insights into some major decisions and practices there. In the product management community, Amazon is known for some unique approaches that many attempt to copy, this book sometimes resembles a love letter to the Amazon way of doing things.

The authors paint a picture of a company with Jeff Bezos at the helm, that is built around principles and practices that are the true hero. Repeatedly, they claim these practices can be reused in others organizations looking to solve similar organizational problems. Implicitly, they are saying that the success of Amazon is now in the DNA of it, and regardless of Jeff Bezos, they have and will continue to succeed.

Signs of being Built-to-Last

Jim Collins and Jerry Porras wrote the best selling book Built-to-Last based on a 6 year research project of exceptional companies, that were an average of 100 years old and continuously outperformed the markets and competition. From that they identified key characteristics to sustaining outsized market success:

• Be a clock builder, not a time teller

• Build your company around a core ideology

• Build a cult-like culture

• Homegrow your management

• Stimulate Progress: BHAGs, Experimentation, and Continuous Improvement

• Preserver the core AND stimulate progress

I see no reason to make up my own criteria, so I will evaluate Amazon based on these 6 key criteria (quick reference). Let’s go…

Be a clock builder, not a time teller

At its core, lasting companies make their business the ultimate product of their success. In a sense, a well built company should be built to continuously innovate and bring new products to market. If it is not, then it may get a few big successes out of the door, but eventually they will fail to innovate.

Further, while a visionary leader may be an excellent time teller (able to make the business work now) they need to focus on clock building, so the business can work into the future without them.

The entire book, Working Backward, is a tribute to the principles and processes that make Amazon a special company. Clearly, the authors believe that Amazon has been built by its visionary leader into a system that can not only survive but continue to be an innovative leader into the future.

We want to be a large company that’s also an invention machine. We want to combine the extraordinary customer-serving capabilities that are enabled by size with the speed of movement, nimbleness, and risk-acceptance mentality normally associated with entrepreneurial start-ups.“ - Bezos, 2015 Letter to Shareholders

Bezos was clearly thinking about Amazon as the core product - an invention machine. Not only is it known for specifically successful products, it is also well known for its culture and practices that include:

• Press Release/Frequently Asked Questions (PR/FAQ). Approach to working backwards. Start with the end result you have in mind as a way to anchor a team around the future they are building towards.

• Six-pagers. Documents - not PowerPoints - used to give an in-depth briefing to review or propose a business idea. Together with the 20 minutes of reading silence to kick-off a meeting to discuss them.

• Bar Raiser Hiring. A process for creating repeatable success in hiring involving strict structure and a specifically trained internal third-party - the Bar Raiser.

• Single-Threaded Leadership. Removes organizational dependencies in order to give teams maximum focus and autonomy to succeed.

• Intense focus on Input Metrics the Weekly Business Review (WBR). Executive teams must focus most of their energy on the critical input metrics that are in their control. They share these in their WBR meetings with cross functional leaders that are expected to go deep into the numbers.

The most notable characteristic about all of these Amazonian practices is that all but one were created with direct involvement of Jeff Bezos. Bar Raising, was not his brainchild, but a consequence of teams failing to hire the best talent once Amazon had gotten too big for him to be directly involved in all hiring.

So the question arises, can Amazon continue to evolve and create new practices necessary for continued success without his leadership?

Build your company around a core ideology

The most successful companies tend to rally around a core ideology, some central focus that can obsessively align the organization across diverse activities. Bezos made a point that Amazon is not lucky to have some singular great advantage, instead they must focus on combining many small advantages. This is the notable runner-up as their core ideology, as expressed through their products and practices.

However, the most clear ideology expressed in many anecdotes throughout the book, is the intense focus on the customer. Of the Amazon Leadership Principles this is #1.

Customer Obsession. Leaders start with the customer and work backwards. They work vigorously to earn and keep customer trust. Although leaders pay attention to competitors, they obsess over customers.

When making significant business decisions, the team repeatedly challenges their ideas against this core principle. Often this means putting their interests second - in the expectations that over-time this is the path to the most business success.

Build a cult-like culture

Much as Disney created their own values and language, being an employee of Amazon, aka Amazonian, has meaning. The well-known practices and principles are a badge of proud insider success to anyone I know that works there. I mean, how many of you have written a book about how great your former company is - like Working Backwards - fawning over it from head to toe?

I wonder if the compensation structures that are heavily equity biased, while capping base salary at $160,000/year even for the most senior execs, could create this sort of viral marketing pyramid scheme? Everyone with lots of equity, even after they leave, has a vested interest to keep up propping up the perception, that Bezos and Amazon are the most amazing place on earth.

This creates a highly competitive situation to get corporate jobs there - that would make Walt Disney envious. Hence, the marketplace for training and coaching would be Amazonians.

The key question, we cannot answer now, will the allure die out post-Bezos? Does it center on Bezos or Amazon, itself? I suspect it will be retained while he remains as Exec Chairman. If Andy Jassy can demonstrate successful continuity then the cult will persist. If there is a hiccup over the next few years, it will be interesting to see how resilient it can be.

Homegrow your management

Built to Last research showed that only 2 of 18 visionary long standing companies, meeting their standards, hired an outside CEO. This reflected 1,700 total years of existence. Only 4 times did these 18 companies hire an outside exec. The comparison comparable company group was 6x more likely to hire outside.

This theme repeated in Collins book Good-to-Great. Often, the cited issue is that boards of directors think bringing in a CEO from the outside is the path to future success. Often, companies make this outside choice even after a successful run by the current CEO whether or not they were the founder.

However, the board is usually influenced by the current CEO. How deep is the leadership team? Has the current CEO built an executive team that can be promoted to the CEO post?

In this regard, Amazon seems well prepared for the future. Bezos is remaining on the board and Andy Jassy, a highly regarded homegrown exec, is taking the helm. Jassy, has been there since 1997 and started AWS, the primary profit generating engine of Amazon.

Stimulate Progress

Big Hairy Audacious Goals (BHAGs), Experimentation, and Continuous Improvement are the hallmarks of consistently successful companies. Bezos has clearly demonstrated the importance of these tools in words and deeds.

I believe we are the best place in the world to fail (we have plenty of practice!), and failure and invention are inseparable twins. To invent you have to experiment, and if you know in advance that it’s going to work, it’s not an experiment. Most large organizations embrace the idea of innovation, but are not willing to suffer the string of failed experiments to get there. - Bezos, 2015 Letter to Shareholders

After some small experiments, Bezos pushed the team hard to develop and launch Amazon Prime while in the middle of the critical Christmas holiday season. This was a response to slowing growth and a recognition that customers greatest problem was dealing with shipping costs.

When Bezos became convinced that digital media was the future, he further recognized that they had to build the hardware device to create a great reading (and simple buying) experience tied to digital. They had never built hardware before. When challenged on the seemingly endless spending on the Kindle bet, Bezos reportedly asked the CFO “How much money do we have?”.

AWS came as a consequence of many small experiments, primarily around providing marketplace participants with simple APIs to integrate Amazon data into their websites. Then iterating on surprising usage data and direct user feedback. While not the original goal, Amazon sniffed out an entire new customer segment that had very different needs than their retail consumers.

In all of these cases, Bezos identified this trend, enabled the organization with single threaded teams, and then set BHAGs to drive them toward the future. Sometimes, with urgency, but sometimes with a commitment to a long game built around incremental progress.

Amazon Prime was a case study in focusing on the long game and being willing to fail in some experiments along the way. They saw technical challenges that doomed the original UnBox service. Followed by business model challenges with the successor Amazon Video On Demand. Bezos was committed, and when he came up with the idea of bundling video with Prime, it changed the game.

Once again, I want to emphasize that while Amazon has been amazing at continuously finding ways to stimulate progress toward massive commercial success, all the major examples in Working Backwards put Bezos at the center.

Either it was Bezos’ idea directly, he instigated progress, or he was unrelenting in steering the teams toward success. Was it not Bezos but the organizational DNA that made this possible? Can Jassy do the same?

Preserver the core AND stimulate progress

Experiments almost never happen in a vacuum. Great companies are able to balance continuous progress on their core business while making the big bets to build out the future.

While Collins found this in his research, I think this fits with the McKinsey Three Horizon’s model. Visionary companies need to keep an eye toward the future, Horizon 3, to develop viable options which driving continuous improvement today, Horizon 1.

Enduring Ideas: Three Horizons of Growth - McKinsey & Co, Dec 2009.

The only thing the McKinsey’s model misjudged, is the pace at which the 3 horizons can apply today especially in the case of Amazon.

Amazon Prime subscription service, while a substantial bit of progress, was incremental in many ways - starting with Super Saver Shipping. They started with free shipping on some orders over $99. Over time, they have increased the available products and reduced shipping times to 2 days or less — and shifted the order size limit into an annual subscription.

Amazon Prime was, at its heart, all about preserving the core business, while energizing its growth. While all the practices of Amazon are designed to do the same, this offering is the greatest single example of handling the ANDs required to do multiple things at the same time.

Conclusions

As far as the textbook goes, it seems like Bezos has built Amazon to last. As I analyzed Amazon against Collins’ criteria, it almost feels like it was his plan all along.

As noted, I can’t shake the real concern that so many of the notable successes in Amazon’s history have been directly tied to the vision and leadership of Bezos himself. I am very curious to see where this ends up in the future.

Is Jassy the real deal? If Amazon is truly built-to-last, it should not matter, as long as he is a good steward of its practices.

Perhaps the most existential risk is Congress’s Case to Break Up Amazon. Long simmering, there are multiple new bills (June 2021) that could force them to break their monopoly power. If this happens, all bets are off.

Multiple times in the last year I have recommended shifting products toward a more product-led growth strategy. The thinking is quite simple — use a great product experience as the primary means drive business growth.

Who uses PLG? The majority of high growth B2B SaaS businesses leverage PLG to some degree today, including Zoom, Notion, Slack, Trello, HubSpot, ConvertKit, and DocuSign.

There is, of course, a lot more to it. How organizations structure themselves, prioritize product investments, and go-to-market are all significantly impacted by a product-led growth (PLG) strategy.

Basics of Product-Led Growth

In particular, when we discuss PLG, we think about minimizing the friction to attract and onboard new users. This has big implications on your marketing. Our goal should be on targeting the pains / needs that specific users have over the benefits that a business customer might experience as a whole.

As such, we see marketing efforts heavily weighted towards educating potential users with content marketing and, often, free to low cost entry points to start trying products out. Their goal is to get a few users at lots of organizations to be sufficiently interested in the offering that they try it out.

Product-Led Growth (PLG) is based on providing value to users directly as a first priority. After demonstrating clear value to users, leverage that into a sales opportunity to create paying “Customers”.

This is where the product-led growth comes in. While marketing is getting the highly qualified leads, it is the products job to convert them into customers through the delivery of great value. Done well, users will encourage additional users to try the product out and, before long, large numbers of users at a single enterprise are using the product.

PLG has taken off in conjunction with the growth of B2B SaaS products. Commonly we see PLG businesses using freemium, free trials, and other low barrier-to-entery approaches to get early adopters in to start scratching their itch.

Traditional Sales & Marketing Led Growth

In more traditional business models, we build software solutions and leverage marketing to create awareness and position our offering in the eyes of potential customers. The we look for big enterprises that might be issuing RFI / RFPs where we can use our sales execution prowess to get shortlisted. With some luck, and a possible short POC, we gain the confidence of the key decision-makers in the business along with procurement, that our solution fits.

Sales negotiates terms of the deal within some constraints dictated by the organization. Then, after a few to several months or more, we execute an agreement with the “customer”. The customer being represented primarily by a budget owner, functional managers, procurement, legal, and - infrequently - some lead users.

After the contracts get fully executed we move to the “handover”. Sales tells the Customer Success team about everything they sold and committed. Then Customer Success schedules their initial kick-off meeting with key stakeholders within the customer team. For the first time this might include a Project Manager and more key end users.

In this model, sometimes referred to as a Sales & Marketing Led Growth Strategy, we see the the user plays a bit part. Sometimes as an influencer but they are often blind to much of the process and getting no value from the vendor throughout much of the sales process.

There are lots of historical reasons for this model and some linger today. Yet, there are many acknowledged problems with such a procurement process and it is rapidly succumbing to PLG.

Where does Sales fit within PLG?

Since PLG flips the traditional sales & marketing model on its head, executives often ask where Sales fits? If the marketing finds users and a great product turns them into customers what role does Sales play?

The truth is that Sales role definitely changes. Rather than focusing on qualifying marketing leads to progress them in the funnel; rather than cold calling with SDRs the volume game - sales new mission is to find existing users that are getting considerable value and help convert them into enterprise agreements.

The gap that most PLG companies find themselves in, especially freemium products, is where they continue to build loyal users and struggle to convert them to paying customers. This is where Sales shines.

A good PLG business will be producing excellent qualified leads for sales to convert. Heavy users. Loyal supporters. Growing user bases within a large enterprise.

So unlike a traditional model of negotiating with procurement and business sponsors on the potential value of your product — a PLG sales exec has a customer being pushed from the bottom up on the value. In fact, a great product, will drive users to push for the paid tier to happen to unlock some remaining feature or usage limitations that will unlock even greater value.

Sales, then is picking the cream of the crop, of highly qualified prospective customers, and simply working to convince organizations that paying crossing some critical need or risk off their plate. Moreover, large enterprises can usually be converted into enterprise deals to reduce the overhead of department by department purchases.

Bottom Line for Sales in PLG

The strategies and tactics that sales rely on within a PLG business are significantly different from traditional sales & marketing led growth. Their attention needs to shift much more to lower volume activities around conversions and expansions.

PLG is basically a dead-end for the high volume ways of the SDR model and a return to the negotiating and high touch relationship building more prominent in earlier days of enterprise software sales.

For those building a new sales organization within a PLG business, be aware of this shift when looking for leadership and team members. This different model tends to require fewer, more strategic thinking sales leaders.

In summary, do not think that just because you are a PLG business that you do not need sales. At some point, large enterprises especially, need the right encouragement to get over the hump and sign that big contact.

Subscribe now

A small terminology, but important, customer-value focused rant this week.

One of my favorite things about startups (and any vibrant organization) is how they reflect on how things are organized and done — always looking to improve. Are we delivering the most value to customers? Can we do it more efficiently? How can we improve our culture? Why do we do it this way?

In had just such a conversation with the head of engineering, at an important client. Something was broken in our software development process and it clearly needs fixing.

The development process is not Scrum, but a newly implemented home-grown agile methodology with a 2-week sprint cadence. The process looks a little like this:

1. Sprint Backlog - Work agreed to include in the planned sprint.

2. In Progress - Work pulled from Backlog and actively being worked on.

3. Review - Work ready for a second set of eyes to review (assuming we don’t use XP or Pair programming to begin with).

4. Done - When coding, review, and other Definition of Done tasks have been met.

5. Deployed - When DevOps deploys the work into Production.

Do you see what is wrong?

Like most engineering teams we have built a process that “feels” complete by having a Done state near the end. Work gets into the Done state when all the engineering, QA work, and other Definition of Done tasks are complete.

The problem is that we see a huge pile up in Done. This pile up actually can include carried over work from one sprint to the next. This is because the process for deploying into production is not fully automated and cannot be done with the flip of a switch.

Instead, DevOps often needs to do some extra manual work to get work from Done deployed to PROD. Further, because of the manual work involved, it usually needs some additional QA.

So I ask the question, is it really Done when engineering has completed their development tasks?

Often times the agreed Definition of Done, includes a checklist item that is “Ready to Deploy”. In an organization that is not yet mature enough to safely, easily, and repeatedly deploy changes into production - I argue that this process is badly defined.

The word Done implies to many that the work is complete. However, if the customer cannot derive value out of the work, then I argue this work ain’t done. Calling it Done will cause external stakeholders to think value has been delivered. Calling it Done will lead product team members to incorrectly think they have crossed the finish line.

I suggest, that any organization that finds itself in a situation where work that is Done is not actually getting into the hands of users (or ready-to-ship in the case of on-prem software) we should revise this standard process model.

With a minor tweak, we can change the discussion internally and externally. Our goal is to deliver value to customers. Unless and until that code is deployed, nobody should consider that work Done.

Now, with this minor tweak in process terminology we create an entirely different discussion between product, engineering, and DevOps. What can we all do to get work Done?

It is clear that we all should be swarming on that Ready to Deploy state and figuring out both how to get the current WIP unstuck and fix the long-term issues that result in a continuing bottleneck in the value stream delivery.

As long as that Done column is empty, we have achieved nothing for our customers.

Product Management must standup for Customer in the definition of such internal processes to ensure it is designed in their interest. Calling something Done that is not, is clearly not in the interest of any Customer.

Words matter. They impact the mindset of the team. The mindset impacts the outcomes achieved. When your Deployment process becomes fully automated, immediate, and error free, then I encourage you to switch back to the old way of calling work Done before Deployment.

Share

When I started in product management, I did not have the benefit of having a great designer or design team around me. As I work with a variety of startups and mature enterprises today, I find that this continues to be a gap in many organizations.

As product leaders, whether we have these experts on the team or not, we need to build up the capacity to assess the quality of the user experience of our products. For me, after years of experience, I built up my own hack-y view of what makes a great user experience.

I would perform this evaluation when inheriting a new product, acquiring a business, starting a new job, or as guiding principles when building a new product. Concepts include minimize clicks, consistency in design, provide the user timely feedback, use familiar design patterns, etc.

It turns out that UX experts have also realized that there are some basic rules they can quickly apply to any product to assess the quality of the user experience — these are generally referred to as Design Heuristics.

A heuristic evaluation is a usability inspection method for computer software that helps to identify usability problems in the user interface (UI) design. - Wikipedia

10 Usability Design Heuristics from NN/Group

As best I can tell, Jakob Nielsen published the original set of heuristics in 1994. He and Don Norman (author of The Design of Everyday Things) now run a design consultancy called NN/g Nielsen Norman Group. On their site, they provide tons of great free resources (e.g. pdf) including Nielsen’s updated list of heuristics.

There are a number of other variations of heuristics from 7 to 20 of them, but knowing and applying this list will get the typical product to minimally good usability.

Without further ado, here are the top 10 heuristics.

1. Visibility of System Status - Give the user feedback when they take an action. Let them know the application is doing something.

2. Match between System and the Real World - Limit inventing new terms and concepts that could simply apply language already familiar to your users.

3. User Control and Freedom - Make users confident that if they make a bad action they can simply undo it. Fear of mistakes slows users down and makes them anxious.

4. Consistency and Standards - User learn faster when products are internally consistent in their design patterns for solving the same type of problem - such as displaying warning info, layout of data entry forms, or in their microcopy. This rule also applies to consistency is design patterns with other applications your users may commonly use. Reinventing how a login form works or how to sort tabular data often harms usability.

5. Error Prevention - Design to reduce the possibility that users can make mistakes - give them confirmation options before destructive actions, minimize memory recall, limit complex multi-step activities.

6. Recognition Rather than Recall - Providing users prompting text and context reduces the cognitive load on a user to perform a function through recognition. Some productivity apps highlight speed of use through keyboard shortcuts but this is relying on the user recall which, most of the time, reduces usability.

7. Flexibility and Efficiency of Use - Providing both a reference menu and keyboard shortcuts offers to maximize usability through flexible options of what is most efficient to use. Applications that support personalization are also exhibiting this heuristic.

8. Aesthetic and Minimalistic Design - Any visual element or information on a screen that is not adding value to the user goals are actually getting in the way of it. Minimize features and information display to that which the user is most likely to need. Rarely used features should be hidden, like advanced actions that are often hidden in a ‘more’ menu.

9. Recognize, Diagnose, and Recover from Errors - Error message and warning should seek to explain and help the user recover from the situation gracefully. An HTTP 500 error is just about the most useless info to provide a user.

10. Help and Documentation - In a perfect world users will not need help, but this is rarely the case in complex business applications or for rarely used capabilities. When providing help make it searchable, timely, and as task relevant as possible.

Last Thought

Breaking these rules is easy. Fixing them later, in a complex application, can be hard. Whenever possible, get ahead of the situation by ensuring the entire team is familiar with these rules from early on.

Any good in-house product designer, usability expert, or UX consultant should help you define standards for design that meet these rules. However, lacking these team members is no excuse not to follow them.

Steve Blank says “Your startup is essentially an organization built to search for a repeatable and scalable business model.” (ref)

Having been working with startups for most of my career, I really love this definition. It encapsulates that nature of discovery and volatility that inhabits the life of a startup.

Key activities in building out this business model include defining who your customers and users are, what problems they have, and providing them a solution they are willing to pay for over competitive alternatives.

There are many risks that a startup faces in finding product-market fit for their first product but it doesn’t end there. If you have the perfect product but a lousy market your business will fail. If you have a great product and market but a key competitor introduces a better, lower cost alternative, the rug will be pulled out from under you.

In one startup I am working with, the business model hinges on key data supplier relationships. What happens if they don’t materialize?

So much risk in startups. So much fun for the mildly masochistic.

When things go well, over time the team reduces the risk in discovering this business model. The product comes together, the market takes shape, partners come calling, and customers want more.

One would think that this makes it easier to make decisions. Less risk. You’ve crossed the chasm after all.

However, there is another set of risks that grow just as your business model risk succumbs to relentless attack.

The growing risks are those of the Established Enterprise. While you are building your startup these seem like the nice problems to have. Once you have them, you start to reminisce about the past.

Here are just some of the nice-to-have problems you can look forward to.

• Existing Customers - The biggest risk to established enterprises is messing up relationships with your existing customers. These customers pay your bills and don’t want to be surprised. They want you to keep investing in things of value to them. You need these customers to remain happy to get references and drive those easy expansion sales. How can you innovate if you are stuck keeping existing customers happy?

• Technical and Design Debt - Technology has a way of getting long in the tooth. Over time, solutions from 5-10 years back are no longer the best way to build solutions today. Refactoring, re-engineering, or building an entirely new solution is really difficult because that introduces risk to your steady and reasonably forecastable business model. Not to mention that such an investment is very difficult to progress relative to some incremental patch-work.

• Competitor Blind Spots - As you grow and gain success, you tend to focus on fewer key competitors in a maturing market. This is because you are on on the short list that Gartner recommends to their advisory clients and you consistently go head to head in big opportunities. But the story of successful companies losing their mojo is usually from new startups exploiting an underserved niche in your market.

• Underserved Niche - Speaking of the niche problems. Usually these are not big enough for your successful business to invest in. Yet, this is probably the exact same type of “mini” market you got your initial start in before maturing your business and market.

If we look at the aggregate picture of Business Model Risk decreasing while Established Enterprise risk grows we have a picture like the following.

There is a definite period of time when you still have not removed the startup risks but the established enterprise risks are growing rapidly. This is a no mans land of risk management.

Managing these types of risk takes different management skills. Moreover, when you identify you are in this cross-over range, you need to be careful not to over emphasize one or the other.

Take customer risk. As a startup still finding its business model, you will likely have many multiples of your existing customer base ahead of you. If you start working too hard to drive satisfaction to all existing customers you may miss the opportunity to find the future growth necessary to survive long-term. What this means is that you need to be very intentional about how you invest in existing customers, being sure to concentrate on just the right customer segments.

Risks never diminish entirely. They just transform as your startup matures.

Subscribe now

Last week I wrote about steps for complex problem solving. This week I want to take a step back to define what a complex problem actually is and why it matters to identify problems as such.

Here is a good definition to start with.

Complex problems are messy, unstable, unpredictable, confounding and don’t come with right answers, only best attempts. These problems require new solutions created specifically for the circumstances, and you can only know that you’ve found a good one in retrospect. 

Skip Richard

Why is it important to identify complex problems and differentiate them from complicated problems? How you solve a complex problem is different than a complicated one.

So that begs the question, what is a complicated problem?

Complicated problems can be hard to solve, but they are addressable with rules and recipes, like the algorithms that place ads on your Twitter feed. They also can be resolved with systems and processes, like the hierarchical structure that most companies use to command and control employees.

Theodore Kinni

This article was instigated by a problem I had to solve this weekend. I went into my based laundry room to a bit of stinky water on the floor. After some investigation I realized the problem was my ejector pump was failing to work. Sewage from my basement bathroom was not getting removed from my house.

After a bit of Youtube handyman work, I identified the root cause of my problem. Started to do my own repair before realizing I should just hire an expert. This is a complicated problem and I don’t want to waste my entire weekend running back-and-forth to the hardware store.

Complex versus Complicated Problems

As Product Leaders our days are filled with identifying, prioritizing, and solving problems. We need to apply the different tools for different classes of problem solving and have different expectations.

Once identified, complicated problems can be solved by applying the right expertise. This expertise can be learned in order to solve these problems predictably, successfully, and repeatedly.

Examples in our product lives may include:

• The production service is down - an expert knows exactly how to restore it.

• We need a report on usage metrics - an expert knows exactly how to create it.

• A new customer needs to be on-boarded - grab the right expert and get it done.

Complex problems often have many alternative solutions that can have varying degrees of successful outcomes. In fact, the outcomes themselves may be varied. In complex problem solving literature a typical example is global warming.

However, we don’t need to be dealing with such enormous issues to face complex problems. In fact, the majority of problems that product managers need to tackle are complex ones.

• What is the correct product strategy and roadmap?

• Should we prioritize technical debt over immediate user value?

• How do we measure user satisfaction?

• When will this be delivered?

• Should we commit to a prospect that we will make this change?

The fact is that, these questions do not have singularly correct answers. They are complex problems.

If we seek an expert to solve them as if they were complicated problems we will be disappointed in their lack of certainty, in how long it takes to arrive at an answer, and (potentially) the long term results that don’t match expectations.

Often businesses will hire consultants to solve complex problems but expect them to provide “the” right answer or recommendation. Most consultants and advisors are providing services to tackle complex problems. As such, it should be expected that some people will disagree with their solution.

Identifying Complex Problems.

Frequently, we take a complex problem and expect to have “the” solution identified through the application of expertise. When that clarity of solution is not apparent we get frustrated and feel like progress is not being made. This is because we are not properly identifying this as a complex problem from the start.

Once we identify a problem is complex we need to be comfortable forging ahead with all uncertainty that any solution might still carry. There is no certainty here.

How can we identify these complex problems? There are a variety of fields that have studied this issue. Here are the key traits from Joachim Funke (Encyclopedia of the Sciences of Learning, Jan 2012).

1. Complexity of the problem situation. A large number of variables in the problem space.

2. Connectivity between involved variables. Many variables impact each other.

3. Dynamics of the situation. The problem is evolving without intervention and intervention may bring about additional changing problem variables.

4. Intransparency. Missing information on the problem and goals of the solution.

5. Polytely. Multiple conflicting goals present.

FastCompany has provided some slightly different attributes to identify for business problems:

• Complexity renders the old playbook obsolete. What used to work will no longer.

• Complexity doesn’t call a timeout. Speed of decision-making, with flexibility is key.

• Complexity moves at an exponential pace. Organizations need to be built to handle repeated complex problem solving as a core process.

Conclusion

My ejector pump will be fixed by Tuesday, because I have an expert coming in to deal with it. When faced with a complicated problem, get the right expert involved.

When tackling complex problems, first recognize them as such. Do not bring in an expert expecting it to be perfectly solved.

Learn to respond and set expectations for solutions that will never be perfect but only one possible best path forward based on optimizing for some of the variables.

Subscribe now

My inspiration this week comes from a tweet and reply on how to tackle complex problems.

I have frequently witnessed a bias among product teams that upon learning about a complex problem they seek to solve it head on. Kind of like @kostadis_tech reply tweet above.

From a product management statement this is almost always the wrong approach. Why? Because solving for all the complexity of a given problem is not good business. It tends to over-emphasize edge cases and misses the forest for the trees.

If we don’t solve a complex problem with a complex solution, then how do we address it? Here are the four options that like to consider.

Often complex problems have multiple solution options.

1. Ignore the problem.

2. Reframe the problem.

3. Approximate a solution.

4. Incrementally attack the problem.

1. Ignore the Problem

I know this is the least comfortable option for most development teams to consider. However, if you have been in the trenches long enough you will find that some complex problems vanish on their own over time.

One scenario I have seen repeatedly over time is landing a big new customer that has some “deal breaker” requirements. Far too big for you to tackle in the next few weeks or months but important enough that the customer wants you to commit to putting it on the long term roadmap or no deal.

This is not necessarily a technically challenging problem but it is complex to the business. Do you go after that whale? What about the other big accounts you just made commitments to? What about the other 80% of your business that don’t care about these extreme enterprise asks? You have lots of variables and no good way to fully assess the costs and risks relative to the opportunity.

You know that this is not part of your current strategy. Yet, in the chase for revenue and new marquee logos, you agree to put it on the plan with every intention of eventually working it in.

18 months later, the executive sponsor at that customer has been promoted and nobody left in the organization remembers the commitment. The customer is happy and giving references.

We can argue if this was ignoring the problem or just “waiting it out” but time and time again I have seen this type of complex problem evaporate over time.

The point here is not to ignore all complex long-term commitments. Instead, it is to ensure you don’t over think them as a default response.

2. Reframe the Problem

This is where you earn your pay as a product manager. While you can leverage the cross functional product team in reframing a problem, often you are the one bringing the problem to the team.

You may not even realize the technical or logical complexity of the problem that you determined to be a priority. Yet, here the team comes to the initial conclusion that it will be extremely challenging to solve the problem. At this point, many product teams start digging in to solve it.

As the PM, it is your job to ensure the problem is looked at from many directions. This is the root of “5 Why’s”. It is also exemplified by the slow Elevator Problem, where the innovative solution could only be discovered when it was realized that the slow elevators were not the problem, but people being bored waiting for them was.

Many complex problems can also be tackled by first reframing.

3. Approximate a Solution

One complex challenge that I have encountered in multiple enterprise applications is around authorizations. As your product gets used by larger and more sophisticated enterprises they continue to pile edge case scenarios to be covered.

What I have learned from analyzing these problems at length and implementing very sophisticated role based authorization mechanisms to address the 99.9% situations is that it is not necessary. In the vast majority of cases, a solution design that would have solved for 75% of *possible* cases would have been sufficient for 99% of my customers. That last 25% of possible needs are usually the hardest to solve for.

Importantly, those sophisticated permissions are harder to maintain, harder to test, harder to integrate with other enterprise auth systems, and are harder to train people to use.

Bottom line, approximating a good enough solution is frequently the superior product decision.

4. Incrementally Attack the Problem

Finally, at times, we have no choice but to tackle a complex problem head on. When we do, we should be using an incremental approach to build, measure, and learn as we go.

By their nature, complex problems have many moving parts and multiple possible “right” answers. By incrementally attacking these problems, you give yourself the opportunity to reassess continually as to what to do next.

Sometimes it will be to continue building out the requisite complex solution with adjustments based on feedback — but other times you may find an opportunity to short circuit the process with one of the short cut alternatives I have previously laid out.

Conclusion

All complex problems do not require a complex solution.

Share

I was inspired this week by a Tweet from Hà Phan to write an article on UX Design.

I am not a UX Designer but I have dabbled for many years. For me, seeing this Tweet, made me want to take some notes and see what I could learn. In part, because I am currently looking to build out a Design function with a startup I am working with (DM me if you need to know more).

TL;DR — UX Design has multiple sub-areas of expertise. I have collected the top recommended books for product people that are new to UX Design and created a public Amazon list for your easy reference: UX Books for PMs. For easy reference jump down to Where to Start.

My top pick from the bunch, for Product Leaders including Startup CEOs, to get a quick understanding of UX and how to build this capacity in your org is: What CEOs Need to Know About Design

The Recommendations Brought Back Memories

I don’t recall any specific coursework to UX when taking engineering, MIS, or management classes back to my undergrad work. The closest material may have been from Organizational Behavior Management, where I learned about user studies and the Hawthorne Effect.

Early in my career, I believed I had a deficiency in understanding my users.

I think, it first arose when I researched best practices for writing requirements around 2004. I eventually discovered MRDs, PRDs, and Use Cases. Before this time I think I was mostly winging it to be honest.

Through these practices and artifacts, I was learning about a big focal point was market and user research. Not just how to solve the problems but understanding the real context first. The “user persona”, “actor”, or “stakeholder” were foundational.

Additionally, I was lucky enough to be thrown in front of existing and prospective customers frequently. Usually, it was to help sell. Sometimes to train them. Sometimes to offer support or discuss our roadmap for the future.

What I learned in these encounters is that customers often asked for specific solutions to their problems. Sales would happily say yes to all of them (I am only half-joking here). Yet, with a few curious questions, I was able to learn a bit more and find their underlying motivations behind those requests. Also, I could learn how important it would be to solve these problems.

By 2005, I was buying books to accelerate my learning and had joined the PDMA devouring their Visions magazine and Journal of Product Innovation Management.

One of my first UX books was targeted at getting more out of my user research. When Hà asked for recommendations, Neil Churcher (@neilchurcher) called out Observing the User Experience as being an excellent benchmark. This was the book really started me further down the road of UX Design.

Somewhere around then I learn about Edward Tufte and his amazing book The Visual Design of Quantitative Information. The books educated me on visual design history, chartjunk, and much more. Often cited from this book is the amazing information visualization from a civil engineer named Charles Joeseph Minard dating back to the French invasion of Russia in 1812-13.

By this time I was getting a good sense that this field of study was much bigger than interviewing users and how to visualize data. As the field has evolved rapidly since the 1970’s we have coined terms like Human-Computer Interaction, User-Centered Design, User Experience Design, Visual Design, Interaction Design, Information Architecture, and Usability. Wrapping all of these up we now often use the word Product Design.

In truth, this broad field seems to have evolved as rapidly as technology itself in the last 30 years.

What should a PM learn about UX Design today?

Let’s agree that we should not get too hung up on terminology and titles. It is more about the concepts and practices that really matter. Titles and scope of responsibilities can differ across organizations.

As a start, it is vitally important the PMs understand why UX Design is important to both users and the business. How can good design increase CSAT and sales? How can research help determine priorities and reduce market risk?

Next, we need to consider that there are some practices of UX Design that are often carried out by Product Managers. In particular, this can be user research and prototyping in smaller teams. Maybe even writing micro-copy within the application.

As organizations and teams scale, PMs may have less of this opportunity but understanding the purpose of these practices and tools commonly used can be helpful in improving internal team communication.

Finally, PMs must understand where UX Design fits into the product development process of the organization. Both from a high-level process perspective and how work technically moves through iterations and into engineering.

Once you have all of these basics covered you will then be more effective in working with this vital contributor to the product team.

Where to Start?

This is where that amazing list of recommendations finally comes into play. Here is how I break-down some of the top recommendations from the Twitter community.

Books on Why Design is Important

For those that need to first be convinced the Design is important to your products. These are the books to get started.

• How Design Makes the World by Scott Berkun

• Design of Everyday Things by Don Norman

• Don’t Make Me Think by Steve Krug

• The Mom Test by Rob Fitzpatrick

Details on Design Practices

If you are already a believer in the value of Design, then these books get you started with practices that work.

• Build Better Products by Laura Klein

• Interviewing Users by Steve Portigal

• Observing the User Experience by Mike Kuniavsky

• Sketching User Experiences by Bill Buxton

Building Design into your Organization

If you are in leadership, already believe in the value of design to your business, but need to know where to get started, how to hire designers, and how to further this competency within your organization these are the books for you.

• What CEOs Need to Know About Design by Audrey Crane

• Sense & Respond by Jeff Gothelf and Josh Seiden

• Org Design for Design Orgs by Peter Merholz and Kristin Skinner

In Conclusion

I became a believer in the importance of good design a long time ago when I saw users struggling with my B2B software. We always focused on the buyers and since they often didn’t involve users in their purchase decisions it didn’t make sense to prioritize design.

Then came the iPhone and social media apps with their design concepts that users, even non-tech savvy users, started to encounter frequently. This elevated expectations for how software should work for the users. They started complaining to management more about poorly designed business software.

Next came freemium SaaS products and product-led growth in general. Tech was entering the workplace from the bottom up. Not via procurement procedures or winning over executive decision-makers that never actually use the software.

If you are in Product Management or Product Leadership, UX Design is not a nice-to-have that can wait for later any longer.

For your reference: For me right now, What CEOs Need to Know About Design is helping me figure how to build a new design org. You can find all the books recommended above and many more on my Amazon list: UX Books for PMs.

At its heart, the concept says that a product is more than just a set of functionality delivered in an application. It is the sum total of the experiences that customers have directly and indirectly with that product.

Often the discussion I have with Product Leaders is that no single person is responsible for this whole product. Yet, on the other hand, we have people across the organization wanting to get more involved in product.

As I was thinking about these two scenarios, it occurred to me that connecting all of these stakeholders to their role in The Whole Product can start to address both issues.

On the one hand, stakeholders can learn of the impact they have already on the product. On the other, it enables more people to standup and own their piece of the puzzle. Combined, this moves the organization towards Whole Product thinking for the benefit of the customer.

It is the job of the Product Leader to evangelize and coalesce the organization behind the Whole Product.

Mapping Roles to The Whole Product

Everyone in the organization has a role in The Whole Product that is experienced by the customer. This feels somewhat like saying “everyone is in sales”, but still, I do believe it.

Core Product Team

There is a group of people that focus that vast majority of their time on working on improving the product and the value it provides to customers. This team, the Core Product Team, is usually comprised of the Product Manager, UX Designer, and Engineers.

They are most directly responsible for the specific functionality of the product, how well it is designed, and its overall quality.

Depending on the organization, and its go-to-market motion, they may have a significant role in setting customer expectations for what is in the product and how it should be expected to work. For example, if a company uses a freemium or trial subscription model, the product team will have a significant role is setting expectations for continued use.

If the organization is more sales led, the Expected product may also be the domain of others like Sales and Product Marketing. These teams often shape customer expectations of the product before they get to actually use it.

Augmented Product Team

While the Core Product Team is focused on the product every single day, the Augmented Product Team is providing a tremendous amount of value-add to customers beyond the software offering itself.

Key stakeholders in the Augmented Product Team include Sales, Product Marketing, Business Development, Customer Success, and Subject Matter Experts. Let’s take a look at the value to customers each may provide.

• Sales & Account Management - Help customers see potential business value from leveraging a product and understand what the experience will be like working with your organization. Sometimes, this may be by connecting prospects with existing customers where they may gain insights into industry best practices.

• Business Development - This role varies but often BD is charged with solution partnerships to help extend the value proposition of the product. This is often done in concert with Product Management where they are constantly looking to find innovative ways to add value to the product where the company is not directly investing themselves. This adds direct benefit to customers by added valuable features or reducing the cost of integrated solutions.

• Product Marketing - Like sales, PMM, may help customers envision where they can get value. Through content marketing, events, and community management, customers can learn how to leverage the product and how to manage processes related to the product.

• Customer Success - Whether assisting with on-boarding, training, or answering how-to questions in support, many products are nearly worthless without this value add.

• Subject Matter Experts - These unusual creatures :) often float in the territory between go-to-market, market analysis, and product definition. Their domain expertise is critical to helping direct research, advise best practices to customers, and help ensure key features are effectively communicated. In many organizations, SMEs are made directly available to customers for advice and feedback as well. This is a clear product value-add.

While all of these stakeholders are acting as an extended part of the product, they also form a critical conduit for feedback. This feedback drives a better future core product: Sales tells us what prospects find critical; PMM keeps tabs on competitor positioning; and CS tells us about on-boarding challenges.

Whole Product Team

Finally, we have people that seem far removed from the product but very much shape both the offering and the perception of the offering that customers end-up buying.

The Potential Product, is not just what it is today, but what it can be for customers when they are getting the most from it, and what how it will change things for the better in the future.

Internal stakeholders added value to the Potential Product:

• CEO - Communicates relentlessly about the better future based on where the product and business are going. Prospects want to be on this ride.

• Board of Directors - Especially in startups, guides the organization through obstacles and toward optimal investment decisions. Done well, outcomes for the company should be aligned with those for their customers.

• Corporate Marketing - Builds a pipeline of the right type of customers. By keeping focus in messaging, this ensures that product investments don’t need to splinter into too many directions. They often nurture relationships with industry analysts that provide key market insights back to the product team.

• HR - All about getting the right team together and helping build an innovative product culture. This is critical to ensuring the future can be continuously brighter for existing customers.

Finally, there is a piece of the Potential Product, that is buoyed through the partners an organization keeps. These may be channel partners that supply critical value-added services and support. They may also be data and technology partners that enable your product to provide greater value.

Through partnering with the right external parties, customers can gain significant pass-through value in the product in a seamless manner.

Conclusion

The bottom line here is that every stakeholder in the organization plays a role in the value created and delivered to the customer. Sometimes, this value is directly in the core product offering, but often times it extends well outside of it.

Each of these stakeholders should be aware of the important part they play in providing this valuable Whole Product to the customer. The person most directly responsible for this Whole Product is often the Head of Product for the company or a particular product area.

As this Head of Product defines and rallies the entire organization around a clear Vision and Product Strategy, it empowers all of these other stakeholders to drive it forward — for the benefit of the customer.

Enough about my adventure and on to the article. If you find value in this please let me know in the comments and share with your product people.

Share

Product Manager Assessment

Over the course of my career, I have had to develop some assessment of competency for Product Managers and Product Marketers on multiple occasions. Usually I have broken this into three major buckets of competency: Domain, Practices, and Soft Skills.

I have done this for the benefit of assessing and developing large organizations. I have also done this for my own self-assessment and that of product managers I have had the benefit of coaching.

Marty Cagan and Chris Jones recent book Empowered catalyzed me to rethink my assessment a bit. I have shifted the major categories, replaced soft skills with “people skills & related competencies” and setup a new template that can be useful no matter if you are a novice PM or a VP in charge of a portfolio of products.

If you like what they described in Empowered, you could now take this as a practical tool for implementing a self assessment or a coaching program.

Download the Assessment

Quick Overview and How to Use

The PM Assessment is quite simple for all you smart people out there. Each row represents a high level competency for assessment. I have a short name and then some description to explain what you should be assessed for on that topic.

To the right is a “You” column for entering how you assess yourself on a scale of 1-5. A “1” represents a beginner with little to no experience. A “5” reflects you having obtained, what could be described objectively, as expert status.

The four columns to the far right are benchmarks to measure yourself against. It is important to recognize that once you have achieved a score, then get promoted or switch product area responsibilities, that score can reset to a lower score.

You don’t become a “5” then have that on any new job. In your new job, whether it is in the same company or a new one, you will need to reassess where you are to start rebuilding specific competencies - especially in the category of Product Expertise.

Even your Practices & Skills may not be wholly transferrable. You must reassess to determine where you have gaps worth focusing energy to close.

Finally, the benchmark scores I provide are quit intentional but they are not universal to all situations. Consider, if you are the first PM hire at a company or if you are one of 50 PMs in a deep career ladder. So adjust the benchmarks to fit your unique situation. If you need assistance, I am happy to discuss.

Product Expertise

Product Expertise is how you develop insights to derive the right product strategy. In some markets you may have deep domain experts supporting your work, while in others nobody in the company came from working in that domain themselves.

Continuously researching and understanding what gaps the organization has in its expertise will help you prioritize the information to go after.

To effectively collaborate and understand the business drivers in your organization, you must learn the key players and their function well enough to work with them. As you move up in seniority it is a given that you take the broader business perspective. As a more junior PM, gaining this understanding will help you accelerate support for your plans.

All of these data points are important but, in particular, if you are new to a product area, it is really important to learn as much as you can about your customers, users, and product definition. This is where I would start, as even the most junior PM should become a leading expert here.

Practices and Skills

The most transferrable competencies are those of being an experienced practitioner of product management. How do you perform Product Discovery and Why? How do you prioritize work and plan a roadmap?

While the tools and standards of practice vary between different organizations, these are mostly cumulative throughout your career. Just keep adding arrows to your quiver by continuing seeking out better ways to practice your craft.

At the rate of change today, if you are a 5 and stop learning, you will be a 3 before too long. This is the peril of Dir/VPs that run large organizations who get lost a long the way because they are not as hands on.

People Skills and Other Competencies

I used to focus a lot on soft skills like being curious, analytical, and an effective communicator. Now, my thinking is that in order to attain a high degree of success at any of these areas, you must indirectly possess those soft skills.

Rather than focusing on those soft skills then, I focus on practical application of those soft skills such as Hiring, Collaboration, and Coaching.

Conclusion

That’s the whole Product Manager Assessment. I hope you can make some good use of it and would love feedback on ways to improve it. In my experience, these tools are never perfect but they can help steer you through structured thinking.

Lastly, if you are interested in coaching and don’t have that support within your organization today, please reach out to me. We assess where you are, then set goals for improvement and work together to achieve them.

Get the Product Manager Assessment

Stefano's expertise is around understanding what makes teams motivated and successful. The book has 5 different tools, you'll have to pick up the book to see them all. What I want to focus on here is the one that he went deeper on during the interview with Chad McAllister - the Team Alignment Map.

Team Alignment Map

The Team Alignment Map is a simple tool to help teams drive alignment. Stefano described it as being very useful during the initial formation of a team. However, as I listened to the description of this map, it became clear to me that this could be a simple vehicle to rollout on a quarterly basis during OKR planning.

The four categories are:

• Joint Objectives: Why has this team been brought together?

• Joint Commitments: How will each member contribute?

• Joint Resources: Do you have what is needed to succeed?

• Joint Risks: What could go wrong?

As Stefano tells it, you start with naming the mission as the headline. Then the team jointly discusses these subjects from left to right through the map. Once they get to the Joint Resource and Joint Risks discussion they need to loop back and identify the additional objectives necessary to tackle those risks and resource gaps identifies.

Quarterly Objective Planning

Whether you use OKRs or some other quarterly business planning framework to provide team focus, this tool can be the perfect device to structure those discussions. Too often, with OKRs, organizations will focus on the tactical challenge of what are the objectives we have been assigned? Do we agree? What Key Results can we signup for that can be indicators of driving toward those objectives?

These are fantastic discussions. However, sometimes they miss getting everyone on the team on-board.

By opening up the discussion to the entire Product Team, using the Team Alignment Map as a framework, I believe teams can be more aware of the risks and resource needs going into the new quarter. They can seek to mitigate these BEFORE agreeing to KRs back to their management team.

This doesn't change anything in the OKR process, it only gives a little more structure to ensure fast-moving teams give more thought before committing to their KRs. In the end the whole organization wins through just a little extra forethought.

Conclusion

Once again the team at Strategyzer has come out with an incredibly simple tool that can have real world benefits in ensuring alignment within a Product Team. While Stefano comes from a project management background, his concept of the Team Alignment Map is simple and useful.

While this is a useful tool in many contexts, I think it has a clear fit in OKR setting.

OKRs are about providing a team with alignment during a quarter (or other period). However, the act of defining them as a Team is the triggering event that defines the potential for successfully achieving them. Revisiting this alignment map each quarter will ensure the team is aligned and motivated.

These questions are typically not answered with 100% confidence. More than likely, there is a great deal of risk in each of the answers. Companies fail to address these risks and cease to innovate when they ignore these risks and assume they can guess the way to a certain future.

Modern product thinking recognizes that a repeatable way to address risks is to use the scientific method of defining a hypothesis and run one or more experiments to validate/invalidate it.

Example of Experimentation

Suppose your product analytics show potential users dropping off during on-boarding to your app right at the sign-up form. Based on some anecdotal evidence you believe that the reason you lose potential users here is because sign-up has so much friction. Further, you hypothesize that adding Google Integrated Sign-In would reduce this leaky funnel.

Rather than building the full integration, you can run a quick experiment. Simply, add the option for Google SSO as a sign-up option in a fraction of the time. When the user clicks this option you will evidence to support your hypothesis. To have even better data, you direct them to a message saying this option is not yet available - would they like to sign-up using an alternative method?

If the user chooses an alternative method you just learned this was not the problem but Google SSO is preferable. If they choose "No Thanks" and exit the process there you have strong signal confirming your hypothesis. You just reduced the risk of developing a useful product feature.

Another way we reduce our exposure to risk is through agile and lean product developments. Specifically, the idea of slicing large projects into smaller increments of value delivery. Like Experiments, this gives us a huge benefit of learning and adjusting before investing a more significant amount into capability.

In this article I want to give a very specific example of a mistake I made as as relatively new Director of Product Management.

Move Fast and Break Things

Mark Zuckerberg famously created an internal development motto for its developers "move fast and break things". They have since made this a more measured motto involving stable infrastructure reflecting the side unintended side effects.

While many in the industry (and beyond) now pan this mentality, it drove a culture of trying things. When your top leader, gives you the space to be comfortable in putting your idea into action, you know that failure is ok. This reflected the understanding that if you want a workforce to innovate in the face of risk - failure will occur.

The healthy version of this today, is that organizations want to "Learn Fast". This positive spin reflects a supporting perspective to the individual and team, plus the real desire to create fast feedback loops as iterate toward increasing product goals.

My Failing in Creating a Healthy Product Culture

Earlier in my career, I have a small team of product managers working for me. I was being slowly self-taught as a product leader and just figuring out how to manage a team of people that were mostly new to the product management discipline. We had a lot of professional development to do.

Still, the whole team was awesome and wanted to push things forward.

One of the PMs on my team had an idea he was excited about. It may have come from client conversations or simply pattern matching with other technology products at the time. Our workflow product had a note taking component. Some users would record a lot of notes as they progressed items in the workflow and we wanted to enable them a quick way to find all notes referencing key data like accounts and customer names. This would eventually save them time in audit processes.

The idea was to leverage a popular feature found in online discussion forums at the time, tagging. I pushed back on whether this was the right solution for the problem but it was his product. He worked with the team to design the feature and even demonstrated a mockup at a user group prior to release.

When the updated product was released with his feature (this was on-premises software), it never used. He went around teaching lead users about the feature and its benefits but they just never adopted it.

He learned a lot from this experience about validating his idea more before investing in it.

Unfortunately I think I taught him something else too

For months after the release, I would ask him how the feature was doing. Do we know if anyone is using it yet? Do we have any support requests on it? Does sales use it in demos?

The answers became consistently clear - the feature either didn't solve a real problem or was not a good solution for it.

As a flawed human I did not understand the impact of the continued questions when I knew the answer. To me it become a joke when he would be presenting another planned feature. Worse, I might joke about it in the company of other team members.

I was inhibiting a healthy product culture to grow. Who would want to propose innovative ideas if this is the possible outcome?

I slowly came to this realization as I saw his work, in particular, get more conservative. With the long cycles we had of getting new releases into wide production use, it was nearly a year before I asked him about this issue and I resolved to fix it.

My lesson here, especially for newer product leaders is not to be like this. Instead, pick your team up when something they try does not works as expected. Use the language of learning rather than failure.

Coach them:

• Learning should be celebrated.

• That this is exactly what you want. Learn and adjust.

• Help them discover ways to learn quicker whenever possible.

Conclusion

This story came to my mind the other day and I couldn't help but hope that I am a better product leader today. We have much better practices for fast learning that are widely known and used. Yet, still, it is informative that you may think you follow all the better practices available today but your approach to working with the team is a critical element of a healthy product culture.

If you want to drive innovative you must nurture the right culture.

During the interview Friesen noted how his product fits in Maslow's Hierarchy of Needs as a basic Physiological Need - making it a super important product for humanity.

This got me thinking about Maslow's Hierarchy, where products fit, what it means, and how we can leverage this in our product thinking.

Guaranteed access to quality drinking water is a fundamental human right. But it is also humanity’s greatest challenge.

Cody Friesen

Product Perspectives

As a general rule for product people, I recommend identifying ways to push yourself to look at the world through different perspectives. Using Maslow's Hierarchy of Needs is one such tool you can use to force this and be intentional about it.

Very quickly we can take out products and get a sense of where they fit within Maslow's Hierarchy. The Source hydropanels fits into the absolute bottom of the hierarchy.

Where does your product fit?

Self-Actualization: Products that develop your creativity or enhance your spirit (e.g. Calm, TikTok, WHOOP)

Esteem Needs: Products that drive sense of prestige or accomplishment (e.g. Tesla, United Global Services, Amex Black Card)

Belongingness: Social media, dating, community products and services (e.g. Meetup, Bumble, Facebook, Clubhouse)

Safety Needs: Products that keep you and your family safe and secure (e.g. Ring, Nest, NordVPN)

Physiological Needs: Basic essentials we need to sustain life and related products (e.g. Purple, UberEats, Beyond Meat, Source)

When evaluating your product you may quickly realize that your product does not fit neatly into one level in the hierarchy. Instead, it may be that different features you have in your product fit at different levels of need.

Take Apple Watch as an example. At first, this was definitely a product that drive Esteem Needs. In fact, most products that have an initially limited market of early adopters are probably somehow addressing this type of need. Then you have features of this product, like the ECG, Heart Rate, and Health that can help drive self-actualization for athletes while they may be addressing critical safety needs for other consumers.

How do these perspective impact your product strategy?

I believe that you can discover opportunities for pattern matching by looking for other products addressing the same level of need. For example you may be building yet another task management tool. Where does this fit in the level of human needs?

On a marketing angle you can look at how a product like Superhuman focuses on self actualization, optimizing the talents of the individual user with managing their email inbox. This approach has led to a sustainable adoption growth with a monthly price tag that is entirely non-competitive with free and nearly free email services.

Most email services focus on just getting work done. That is really focusing on the human need to feel a sense of accomplishment (esteem). Similarly, most task management tools are simply about getting stuff done.

Superhuman demonstrates there is a market for both approaches and that picking one, will help you focus your product investment and go-to-market decisions.

Going back to Source water example, you can see that they are on social mission to fulfill a basic human need for water. By their account there are well over a billion people in the world that do not have easy access to a safe and reliable source of water. However, this is also a very capitalist enterprise. Everyone in the world needs water to survive. Everyone does not need to be a rockstar at managing their email load.

How does this impact product strategy? By identifying needs lower down in the hierarchy that you can address, you expand the potential addressable market. You may have to get your price points lower, so your innovations need to focus on cost savings and enabling an excellent distribution reach.

Perhaps your task management tool is not solving the need of water but you may find features that could move it down to safety. Take for example, the prestige that Apple iPhones brought initially. Now as they are more widely distributed, Apple has brought in features like the HealthKit and Find My (People) that move into Safety.

How can you leverage this for personal development?

I think that thinking through Maslow's model as part of your career development can be a useful exercise. In particular, you should ask yourself what type of products do you want to be part of building.

• Products that help a small percentage of the population be their absolute best possible selves?

• Products that focus on the broad psychological needs of individuals and society that can better life for a majority of us?

• Products that tackle the toughest global problems that impact every single person on the planet?

Nothing will fit perfectly into these buckets as you can see, but have this sense of direction can help you focus on the skills you need to develop, the markets you need to follow, and the companies you should target on your next job search.

Conclusion

Maslow's Hierarchy is a great way to view the world and step out of your day-to-day. Using models like this help force us into different patterns of thinking that can unlock new discoveries and approaches that may have other be missed.

Coaches can be hired by an individual or by an organization. Typically, they engage with individual product managers or teams to help them achieve some specific objectives. Just like an Agile Coach may help the Scrum team get better at story splitting or an Executive Coach helps a CEO become more self-aware - Product Coaches often have specific domains of expertise they can help with.

This article explores some of the times when a Product Coach can help.

1. Job search and interview preparation

2. On-boarding in a new company or role

3. Developing specific competencies

4. New Product Leaders

5. Developing a Product Team

Job Search and Interview Prep

Whether you are trying to land your first product management job or advance your career, many people look for a Product Coach to help them fine tune their interview skills. There is a cottage industry of former FAANG Product Managers, in particular, that sell their services to help you hack the particulars of those well-known companies.

Job searches can be daunting. Once finally getting some interviews you want to be at your best. Coaches can help you present your best self and give you the confidence to position your talents effectively. While many interview coaches exist, finding a coach that is specific to Product Management will increase focus around the skills that your target employers want to see today.

The following transitions benefit enormously:

• Switching industries (e.g. FinTech to EdTech)

• Experiencing different company/product lifecycle stage (e.g. move from IBM to a Startup)

• Gaining experience in different business models (e.g. B2B SaaS to B2C Marketplace, Software to IoT+Hardware)

Of course, for many experienced professionals they may not be looking for major market change but just to grow in their leadership opportunities. Since most product managers are not experts in interviewing (on either side of the table) getting coaching is just smart preparation.

On-Boarding in a New Company or Role

Once you land a new job within your existing company or a new one, there is frequently a learning curve. For some organizations they build in mentorship programs for their new employees. These are an awesome accelerator. However, not every organization has this and mentors often focus more on navigating the particulars of the company rather than specific competencies.

If you landed that perfect stretch role, finding a Product Coach to help up-skill you, identify blindspots, and increase your odds of success.

Developing Specific Competencies

Your organization should periodically review the competencies necessary to propel it forward. Where there are gaps teams will often work with external trainers to increase knowledge and attention in specific areas. Some of the common competencies that I have seen companies look to develop:

• Specific Agile Methodologies - like SAFe, Nexus, Scrum, Kanban

• Product Vision and Strategy development

• Product Discovery including Customer Research, Design Sprints

• Data-Led Practices

• Product-Led Growth

While these can often be advanced through formal training, they really gain traction in the organization only through proper support. Many training organizations provide online communities for follow-through support. Product Coaches can sometimes be a better alternative to impersonal online forums and allow greater focus on organizational and personal development goals.

Individual Product Managers are seeking this help now too. Either with corporate training budget or as a personal investment in their own success.

New Product Leaders

When a company hires or promotes a new Product Leader, e.g. Director of Product, VP Product, CPO) often they are experienced veterans in Product Leadership. In their new role they can benefit from an objective perspective as they navigate new organizational challenges.

Another common scenario is when a new Product Leader comes in with no direct product management experience. Often this person will be from Marketing, Business Development, or Engineering. They frequently, have proven themselves to be effective team builders and strong industry expertise. Their gap is often in basic product management competencies and a deep understanding of practices.

For these experienced newbies a Product Coach (after some basic training) can be the difference between 6 months of on the job struggles and rapid learning.

Developing a Product Team

As a Product Leader, one of the most important responsibilities is to develop the right high performing team. This means brining the right people on-board, developing them, organizing effectively, and ensuring the right processes are in place to succeed. There are no obvious right or wrong answers in managing any of this.

Sometimes, external consultants are brought in for large initiatives. However, most of the time, the Product Leadership is tasked with continually furthering the team. Often, these can be challenging efforts and sometimes involve sensitive discussions that can benefit from speaking with other product leaders.

Once again, Product Coaches act as the perfect sounding board. Enabling leaders to develop their thinking and take action with confidence without bogging down or creating internal uncertainties as they what-if various changes.

Summary

Product Coaches are not yet that common throughout the discipline but it is growing quite fast in some areas. Startups, in particular, seem to be embracing the value of augmenting the expertise on their teams with a little expert guidance and feedback.

Just as pro athletes have a strength and conditioning coach, a batting coach, a sport psychology coach, etc. - Product Managers can use specialized coaching to up their game.

There can be many reasons for this split. What we need to keep in mind is that whenever you split roles up the result will be enabling efficiency along one dimension but decreasing it along another.

Product Marketers seek to define key features and benefits of an offering to the market. This is the mirror image of the outcomes product managers build features to drive.

Close alignment between these product development and marketing activities not only saves time but can drive more efficient feedback loops.

Product Marketing

Product Marketers usually sit in the Marketing or Product organization. In my experience, the larger the organization becomes the more they become disconnected from the product development process. Often, a single product marketer might support multiple products. If they report into the Marketing organization it also adds some additional challenges in optimizing the shared goals of a product team.

One key deliverable Product Marketing is usually responsible is positioning the product in the market. Often they will identify a list of marketable features with product management and use this for positioning analysis within their product category.

• What is requested in RFPs?

• What features do analysts care about?

• What features are our competitors highlighting in their marketing?

This helps them to see what might be important to highlight in their marketing efforts. However, that is just a piece of the puzzle they need to communicate.

To help sell potential customers on the value of their offering, they generally seek to tie the key features to benefits.

Features - Attributes of the product that is usually objective facts.

Examples include: Payments are processed in 10 mins, Reporting tool integrates with MongoDB, complies with GDPR.

Benefits - This is a description of the value that customers get from the product. Often product marketers will connect features to benefits.

Example: Because the application complies with GDPR you are able to use it immediately with your customers in the EU without additional operational workarounds.

Results - Proof points to act as evidence that the benefit is not just theoretically possible but that customers have experienced the stated benefits. Sometimes this is communicated via a case study or customer testimonials.

Example: Customer XYZ switched to our product and was immediately able expand their digital offering to Europe from the US with no legal concerns over GDPR.

Product Management

Better practices in Product Management include planning work around a series of desired outcomes. Product Teams perform discovery work to identify the best solutions they can develop to achieve those outcomes.

Outcomes - Generally some desired change in behavior by a stakeholder that supports customer or business goals.

Example: Enable customers to quickly and confidently do business in markets governed by GDPR.

Features - Whether the product team works in features, capabilities, epics, stories or some other unit of described deliverable -- ultimately they discover and build a solution they believe will achieve the desired outcome.

Examples: Ability to download all user data into a zip file, Ability to be removed from the database, Ability to see how all user data is being used.

Keeping Product Management and Product Marketing Aligned

By ensuring early and continuous alignment between Product Management and Product Marketing the Features, Benefits, and Outcomes can all be aligned.

Features will often be described in more granular terms within the product development process than in marketing. However, there is a clear alignment and both teams should understand terminology being used. This way, product marketing will be able to more readily understand features under-development.

Where the true alignment magic happens is between Outcomes - Benefits. We can argue nuance here, but at a high level these are mirror images of each other. Desired Outcomes are what inspire and guide development. When we talk to the market we describe these as Benefits to derived.

By giving Product Marketing early insight into the Outcomes being solved for, they have a better opportunity to plan for how this can most effectively be communicated. Moreover, they can provide feedback to Product Management that can influence prioritization and scope. This feedback is crucial.

Product Management can frequently get overly focused on existing customer and user perspectives, whereas, product marketing often is looking ahead to future customers.

For Product Marketing, they should never try to analyze the features without input from Product Management on why those features were built -- the Desired Outcomes.

Conclusion

Product Marketing is a function often split from Product Management to enable greater organizational scaling. When split in this way, do not lose the fact that a lot of their work. resolves around the exact same concepts but just seen through a different lens.