- The value exchange system
- Constraints on the value exchange system
- Project vs Products vs Services
- The product-led organisation
- What we know and what we don't
- Bad product manager archetypes
- A great product manager
- Strategy
- What is strategy?
- Strategic gaps
- Creating a good strategic framework
- Company-level vision and strategic intents
- Product vision and portfolio
- Product management process
- The product kata
- Understanding the direction and setting success metrics
- Problem exploration
- Solution exploration
- Building and optimising your solution
- The product-led organisation
- Escaping the build trap to become product-led
- Six questions to determine wheter a company is product-led
The build trap is when organizations become stuck measuring their success by outputs rather than outcomes, when they focus more on shipping and developing features rather thant he actual value those things produce. When companies stop producing real value for the users, they begin to lose market share.
You need to look at the entire company, not just at the development team. Are you optimising your organisation to continually produce value? Are you set up to grow and sustain products as a company?
Companies end up in the build trap when they misunderstand value. Instead of associating value with outcomes, they measure value by the number of things they produce.
Customers realises value when their problems are solved. Then and only then do they provide value back to the business. Every feature you build should result in some outcome that is tied back to that business value. When companies do not understand their customers' or users' problems, they cannot possibility define value for them.
Sometimes companies fall under the catch-up game, trying to fast-follow its competitors. This is what happened with Google+ and Facebook, never differentiating enough, just copying. Companies do also overpromise during their sales process, giving customers whatever they take to get the contract signed. The result is a ton of one-off features that satisfied the needs of only one client,r ather than a strategic choice to build what would scale for many clients.
Organisations get stuck in reactive mode, without building with intent. You have to get to know your customers and users, deeply understanding their needs. Companies need to get their employees closer to their customers and users so that they can learn from them.
Your customers and users don't exist in a vacuum, their wants and needs change according to what's around them. The only thing we can do is understand them better to know how to act. Even thought businesses cannot control the customer side, they have full control over their own constraints.
Raise your hand if you went back and iterated on the last thing you shipped
How do you know that what you shipped was successful?
If your answer is around deadlines and finishing with bug-free code, you're likely in a company optimised for outputs instead of outcomes. Outputs are easily quantified things that we produce, like the number of products, features, releases, velocity, etc. Outcomes are the things that result when we finally deliver those features ant the customer problems are solved.
For most companies, their entire structure is optimised to increase the output. To be strategic, we should define and measure value and then celebrate them for delivering on outcomes for our business and users.
- Project Scope out work to be done, create deadlines and milestones, and then have the team get to work.
- Products Deliver value repeatedly to customers and users, without requiring to build something new every time.
- Services Unlike products, they use human labor to primarily deliver value to the user.
Many companies use a combination of products and services to deliver value. A project is a discrete scope of work that has a particular aim. Projects are an essential part of product development, but the mentality of thinking only in projects will cause damage.
A feature enhancement is a project, but your work may not be done when you are finished. You need to keep iterating by scoping out new projects to reach the overall outcome to be successful.
Product-led companies understand that the success of their products is the primary driver of growth and value for their company.
Many companies are instead lead by sales, visionaries or technology, which all land you in the build trap.
Companies let their contracts define their product strategy. Like having 30 features that no-one uses.
Many small companies start of as sales-led, and that can be okay. This way of working does not scale for long. When you have 50 to 100 customers or more, you need to change your strategy to building features that apply to everyone, without customisation.
Consider Apple and Steve Jobs. These type of companies can be very powerful, when you have the right visionary. However, is not sustainable. Innovation needs to be baked in to the system so that one person is not the weakness link.
Companies that are driven by the latest and coolest technology. They often suffer from the lak of a market-facing, value-led strategy.
Technology is critical to a software company success, but it cannot drive the product strategy. Product strategy connects the business, market, and technology together. You need to be able to lead with a value proposition for your users, or you will not be able to make money.
Companies that optimise for their business outcomes. You don't need to hire an entire new team, but changing the mindset is a challenge. You need to begin focusing on outcomes and to adopt an experimental mindset to eliminate uncertainty that what you are building will reach your goals.
Product development is full of uncertainty. It's important to separate out the facts from the things that we need to learn.
When kicking off a project, it's best to begin by identifying what you know to be true about the situation, your known knowns. Facts that you gather from data or critical requirements from customers.
You need to separate these items out as facts and to label those that you are unsure about as our known unknowns. Assumptions that you want to test, turn them into facts, and build to satisfy those facts.
Although we should all listen to our intuition, you should be cautious because this is often where bias thrives.
The unknowns unknowns are the things that you don't know you don't know. They pop up during research.
Product management is the domain of recognising and investigating the known unknowns and of reducing the universe around the unknown unknowns.
Product managers identify features and products that will solve customer problems while achieving business goals. They optimise the Value Exchange System. Product managers are the key to becoming product-led.
A Product manager deeply understands both the business and the customer. They are responsible for synthesising multiple pieces of data, and then determining in which direction the team should move. They keep the team focused on the why are we building this product, and what outcome will it produce? The Chief Product Officer ties together the business outocmes to the roadmpap and represents its impact back to the board.
Under a Waterfall process, the first step for a product manager is to talk to internal stakeholders and ask them for their input and requests. This encourages product managers to always satisfy their stakeholders. After requirements are detailed out, they are usually handled to the designers to create an attractive-looking interface. After the product managers approve the designers' work, the software engineers can begin coding. Coding typically takes months, and for large projects, it can even take years.
Many companies have adopted Agile as it was a silver bullet. Agiles does indeed promote a better way of collaboration and faster method of building software, but it largely ignore how to do effective product management. When you go through the motions without active thinking, you end up with a lot of useless features. We rarely teach product managers how to think, and even if we do, we don't measure this thinking process.
Some common archetypes of bad product managers
Product managers are not the mini-CEOs of a product. Product managers can't change many things a CEO can in an organisation. They don't have the authority over people – because they are not people managers and they need to rely on influencing them. This is a very arrogant product manager archetype who thinks they rule the world.
The job of a product manager is to produce value, not to develop your own ideas.
Start listening to your team. Involve them. Listen to your customers and focus on their problems instead of your own solutions. Fall in love with those problems. Validate your dideas. Turn to concrete evidence, rather than opinions.
Listening to everyone's opinion is important, but it doesn't mean a product manager should implement every suggestion.
This is a product manager who is an order taker. They go to their stakeholders, customers, or managers, ask for what they want, and turn those wants into a list of items to be developed. There is no goal. There is no vision. There is no decision making involved. This is usually the role of a product owner.
So, how these people prioritise? More often than not, the most important person gets their features prioritised. Instead of discovering problems, waiters ask "What do you want?"
They implement ideas without validating them. It's not the customer's job to come up with their own solutions. That is the product manager job.
Waiters are reactive thinkers, not strategic thinkers. Pushing back is essential to building a successful product.
Project managers who are put into product management roles often become waiters waving a calendar.
Product managers are not project managers. Project managers are responsible for the when. Product managers are responsible for the why, why are we building this? How does it deliver value to our customers? How does it help meet the goals of the business?
Agile methodologies distribute the responsibilities of the project manager across the team. These cross-functional teams have all the key players dedicated to ship a feature, so less coordination is needed across departments. Thus, project management is not needed.
Answering why is very different than answering when. It requires a strategic mindset.
The role of a product manager is to work with a team to create the right product that balances business needs with solving user problems. They understand many sides of the company. They need to understand the market and how the business works. They need to truly understand the vision and the goal of the company. They must have deep empathy for the users.
The "product manager" title is misleading, as an effective product manager is not really a manager. To be effective, product managers need to recognise team members' strengths and work with them to achieve the common goal. They need to convince their team and the company on the things they are working are the right things to be building. Influencing skills are essential.
Product managers really own the why, of what they are building. They work with the team to develop ideas and jump in once requirements get validated to make sure that the product being created achieves the goals of the customer, user, and business. It's the team, collectively, that really owns the product, the what.
Product managers should be at the helm of experimentation. Product managers connect the dots. They must be humble, they recognise they don't know all the answers.
The ultimate goal for a product manager is to reduce the risk by focusing on learning.
Great product managers will get further by taking advantage of the skills and expertise of their team. Product management is about looking at the entire system and figuring out how it can product revenue for the company. Product managers need to know just enough to talk with an engineer or a business person. A product manager must be tech literate, not tech fluent in order to make good trade-off decisions.
Although it's valuable for a product manager to know the market well, this is something they can learn.
Always focus on the problem. If you anchor yourself with the why, you will be more likely to build the right thing.
- Why are we making everything digital in the mortgage space?
- Why even do this project?
- What's the desired result that we hope to achieve here?
- What does success look like?
- What happens if we make it all digital and nobody applies for mortgages?
- How are we mitigating that risk?
Too often, product managers dive into creating solutions without thinking through the associated risks.
When organisations hand down solutions, they skip setting success metrics and goals.
The biggest issue reported by leaders is that product managers won't step up and "own the product". Product managers can and should question solutions and push back on things handed down. However, the work required to gather data and prove the solution takes time.
There is some confusion between a product owner and a product manager. In Scrum literature, a product owner:
- Define the product backlog and create actionable user stories for the development teams.
- Groom and prioritise the work in the backlog.
- Accept the completed user stories to make sure the work fulfills the criteria.
Product owner is a role you play on a Scrum team. Product manager is a career. Product management and Scrum can work well together, but product management is not dependent on Scrum.
Most organisations do not give their people the necessary time to do product vision and research work. They would rather hold them responsible for a steady stream of outputs and measure success based on stacking backlogs and writing stories.
Product managers play some key roles, but one of the most important ones is being able to marry the business goals with the customer goals to achieve value. Good product managers figure out how to achieve goals for the business by creating or optimising products, all with a view toward solving actual customer problems.
Without a Scrum team or with a smaller team, you might be doing more strategy and validation work for a product that has not been defined yet. With a Scrum team, you might be more focused on the execution of solutions. As a manager of product managers, you might be leading strategy for a larger part of the product and coaching your teams to discover and execute well.
With a good strategy framework in place and ruthless prioritisation around a few key goals, one person can effectively talk to customers, understand their problems, and help to define the solutions with the team.
Tactical work for a product manager focuses on the shorter-term actions of building features and getting out of the door, scoping out work and crunching the data to determine what to do next.
Strategic work is about positioning the product and the company to win in the market and achieve goals, it looks like the future state of the product and company.
Operational work is about tying the strategy back to the tactical work. Here is were Product Managers create a roadmap that connects the current and the future state of the product.
Open up this role to people making the switch into product management. Pair them with a senior product manager to teach them the ropes.
Works with a development team and UX designers to ideate and build the right solutions for the customers, talking to users, synthesising the data, making the decisions from a feature perspective. Product managers are usually responsible for a feature or a set of features part of a larger product.
The product manager needs to be strategic enough to help craft the vision of the features and how they fit into the overall product but tactical enough to ensure a smooth execution of the solution. They tend to skew more operational than strategic at this level due to their shorter-term impact the delivery of the roadmap.
The danger is when a product manager is 100% operational, focusing only on shipping products and not on optimising the feature. When they optimise for the day-to-day execution of the team they usually fall behind in the necessary strategy and vision for the features to succeed. It's imperative to push back as much project management effort as possible to the team and trust them to deliver.
Product managers are part of a larger product team, feeding data about the success of features to product people. This helps inform the strategy and direction of the product portfolio and organisation.
Same as product managers but they also oversee more scope or a more complex product. It is as high in the product management field as you can go as an individual contributor. They want to focus on building products instead of growing a team. You must balance being highly strategic and highly operational.
This role is for people who like difficult product problems. They are usually entrepreneurial, and that's a great trait because they will be the ones to start new product lines for businesses.
At a certain point, the company will grow enough that there are too many people reporting into the head of product. A director of product becomes necessary to help promote strategic alignment and operational efficiency.
They oversee a group of product managers who are aligned around a product in a portfolio or a product line. They ar responsible for the strategic roadmap of the product, making sure all product managers are aligned by the appropriate goals and working in the most important items to move the product forward.
This is someone who oversees the strategy and operations for an entire product line. They set the vision and goals for the overall product. In large enterprises they are also directly responsible for financial success of their product line, not just the delivery of product features.
A VP of product is usually the highest level in smaller companies because there is only one product and not multiple product lines. A successful VP of product needs to fundamentally be more of a strategic person and they know that in order to scale their organisation, they need to hire in people who take over the tactical and operational components.
A CPO oversees a company's entire product portfolio and they ensure it works together to achieve the company goals. Although a VP of product needs to understand how their product roadmap affects the economics of the company, a CPO needs to do that across all products. They work with VPs of product to ensure that every product is strategically aligned to the company's objectives and each product has what it needs, from a resource and people perspective, to reach the established goals.
A CPO needs to be able to interface at the board level. A successful CPO needs to be able to translate their actions into terms the board will understand.
They inspire confidence, empathise, and are relentless and resilient
To inspire confidence, CPOs work across many functions to gain buy-in and alignment, they get through things through influence versus direct authority. By empathising with the other members of their peer group, their customers and their teams, CPOs can find a way forward that aligns all the goals.
Finally, a CPO must be relentless and resilient. They need to desire to dig in and find out what is working and what is not, assessing and analysing, trying to prove their hypothesis right and wrong, and holding themselves accountable to data.
Having a strong product leader in the C-Suite is a critical step to becoming product-led.
Companies tend to organise in three main ways: value streams, features, and technical components.
Teams organised around features usually do so in order to get ownership over every part of the product, although this is good if you are starting from scratch, it promotes a very output-oriented mindset. We tend to look for ways to develop more things related to our little slice of the product. When features are stable, we should monitor them and then move on to more important work needed to support our strategy.
When companies are small, you can organise effectively around goals you are trying to reach. This is the case for TransferWise. One team is focused on retention, another on implementing new currencies, and another on acquiring customers. Each of these teams has ownership of their goal and is judged for success based on their outcomes. It takes a huge amount of coordination across the product teams, so everyone is responsible for collaborating intensely with one another. This structure creates a nice redundancy across the company, so important information about a single product is not stuck in the head of one person.
As companies scale, this may not be a viable option. A value stream is all activities needed to deliver value to the customer. That includes process from discovering the problem, setting goals, and conceiving of the idea, to delivering the actual product or service. Every organisation should strive to optimise this flow in order to get value out the door faster to customers, and in order to do so, it makes sense to organise your teams around the value stream.
First you begin with the customer or user, whomever is consuming your product at the end of the day. What is the value that you are providing to them? Then work backward. FInd the touchpoints they have with your company to receive that value. How do you organise to optimise and streamline that journey for them? How do you optimise to provide more value, faster?
Many companies are confused by the word product. If your app, interface, or feature is not inherently adding value on its own, it's just a piece of the entire product. You have to look beyond just that piece to understand how to manage for value delivery and creation.
For example, car insurance provides peace of mind in case you get into an accident, that's value. An iPhone app that allows you to manage your car insurance is only a piece of that product's value stream; the app on its own is not enough value.
You can still have a product manager owning that iPhone app experience, but you must make sure that they are part of a larger division that holds the true value, the car insurance division. This structure makes it possible to set strategy at the division level. with the product manager able to execute on product initiatives that tie to their product. Keeping the strategy and the value execution together is key.
By minimising the number of layers and by giving product managers more scope over their product areas, you can effectively create a product organisation with a structure that supports the product strategy.
The company had 20 product teams organised around components. "How should we build this organisation?" "We need to restructure around value streams". We needed to start by hiring an experienced chief product officer. We have a great VP of product, good at the tactical and strategic work for a single product vision, but unfortunately she doesn't understand how to manage a portfolio of products. We also need more senior people.
You can't build an organisational structure without a product vision, because the value streams are not apparent.
To make considerable impact, you need to have everyone going in the same direction, working toward the same goals.
A good strategy is not a plan; it's a framework that helps you make decisions. Product strategy connects the vision and economic outcomes of the company back to product portfolio, individual product initiatives, and solution options for the teams. Strategy creation is the process of determining the direction of the company and developing the framework in which people make decisions.
Netflix's vision in 2005 was "to provide movies and TV shows in the most convenient and easy way for customers", they didn't see DVDs as the end point. They knew that if they truly wanted to become the most convenient vehicle by which people would watch movies, it had to figure out a way to get entertainment into the hands of its users faster. Because they started early on, their streaming technology wasn't fast enough to download movies, but once the internet got faster they company expected to see more people downloading videos. But it didn't happen. Netflix realised that only internet-enabled devices at the time were laptops and home computers, and that they weren't the most convenient and delightful way to watch movies. Netflix decided to build its own internet-connected device plugged into TVs for years but a few days before lunch, Reed Hastings shut it down. Hastings realised if they launched their own devide, they couldn't partner with anyone else. He would be in the business of hardware, not software or entertainment, and that wasn't part of Netflix core vision; it didn't align with the overall strategy.
Netflix is an example of a company that got out of the build trap, they focused the entire company around a solid vision "becoming the best global entertainment distribution service, licensing entertainment content around the world, creating markets that are accesible to film makers, and helping content creators around the world to find a global audience". This vision states not only why the company exists but also the plan for getting there.
Netflix self-organised around key outcomes and strategies to help reach its goals. Gibson Biddle, who was VP of product at Netflix aligned his team around a common guideline for evaluating its product strategy "delight customers, in margin-enhancing, hard-to-copy ways".
| Key strategies | Tactics | Metrics |
|---|---|---|
| Personalised | Ratings Wizard, Netflix Prize | % of customers who rate >= 50 titles at 6 weeks; RMSE |
| Instant | Hub expansion, streaming | % of disks delivered in one day; % of customers who watch >= 15 min/month |
| Margin-enhancing | Previously viewed, advertising, price & plan testing | Gross margin, LTV |
| Easy | Simplify and kill; progressive disclosure | % of customers with >= titles in queue on day one |
The powerful thing about a strategic framework is that it forces you to think about the whole before zooming in on the details. When a company thinks only about the feature-level model, it loses track of the outcomes those features should produce.
You can't figure out the right product until you know what problem are you solving. Often people don't want a strategy, they want a plan. A good strategy isn't a detailed plan. It's a framework that helps you make decisions.
Many companies spend months in "strategic planning" for the following year, creating comprehensive and detailed outlines of the tasks they will accomplish, the cost of those actions, and the revenue they will generate. Thinking of strategy as a plan is what gets us into the build trap. Stephan Bungay, one of the most respected leaders in strategy deployment and creation, in his book "The Art of Action" he writes:
Strategy is a deployable decision-making framework, enabling action to achieve desired outcomes, constrained by current capabilities, coherently aligned to the existing context.
While studying strategy in many organisations, Stephen Bungay discovered that when companies approach strategy as a plan, they often fail.
The Knowledge Gap is the difference between what management would like to know and what the company actually knows.
Instead of seeking more detailed information, upper management should be limiting its direction to defining and communicating the strategic intent, or the goals of the business. The strategic intent communicates where the company is heading and what it desires to achieve when it gets there, it points the team toward the outcomes the business wants to achieve. The company needs to provide room for experimentation and to understand the why before it could suggest the how to solve the problem.
We know there is a problem, the next step is to discover that problem, tackle it with a solution, and then try to optimise the solution so we can increase acquisition.
This is the difference between what people do and what management wants them to do, which is to achieve business goals. Organisations try to fill this gap by providing more detailed instruction; whereas, instead, they should allow each level within the company to define how it will achieve the intent of the next level up.
At one company, I walked around asking all of the product managers on the hundred or so teams why they were working on their current project. I then asked their leaders the same question. I got two different answers. They could not connect the activities of the teams back to the outcomes of the companies because leadership had passed down feature requests rather than expected outcomes and goals. As soon as those feature requests were committed, it was nearly impossible to change them because the company expected them to be delivered. When teams realise customers don't want their solution, they should have the freedom to explore alternative solutions. This is how a product-led organisation should operate.
Product teams need the freedom to explore solutions and to adjust their actions according to the data they receive. Management should feel comfortable granting the necessary autonomy to capable teams. Instead of sending down mandates, organisations should, instead, turn to aligning every level of the company around the why and should give the next layer down the opportunity to figure out the how and report back. When leadership is not aligned at the top, the issues trickle all the way down to teams.
This is the difference between what we expect our actions to achieve and what actually happens. When organisations do not see the results they want, they try to fill the gap by putting more controls in place. However, that is the worst thing you can do in this scenario. Giving individuals and teams the freedom to adjust their actions so that they are in line with their goals is what truly allows them to achieve results.
We should strive to align teams with a framework of goals and direction and then stepping back to give that team the room to explore.
Prescribing fully though-out solutions restricts product teams to only those parameters instead of being able to focus on learning and adjusting their decisions as they go. You need to view strategy in a different way. You should enable action to achieve results.
At Marketly, Product Managers often said
I keep having leaders tell me to own the vision of my product, but I'm not allowed. My manager keeps handling me solutions. Every time I try to suggest something different, I'm shut down.
In contrast to what leaders said
Our product managers won't step up and own the product. I have to keep prescribing things for them, but it's because they don't take initiative.
When teams are not aligned with a clear direction and goals, they cannot effectively make decisions. If they dare to try, much of the time, the leader steps in and says "No, that's not right".
Autonomy is what allows organisations to scale. The alternative is hiring hundreds of thousands of middle managers that lead by authority, telling people what to do. Which is not only inefficient but also causes unnecessary layers in management and a lot of frustration.
Leading by authority is a relic of industrial-age methodologies, when low-skilled workers were supervised closely so that their output was maximised. In the world of software, we don't work this way in. When you have that sort of talent, you need to give people room to make decisions so that you can get the full benefit of their knowledge and skill. That's what a strategic framework promotes.
Marketly CEO originally thought the issues were with the development teams "they aren't going fast enough, they are slacking off", and although the company had OKRs, they were very output-oriented instead of outcome-oriented "Ship the first version of the new teacher platform" or "Delivery by June 2018". Key results weren't tied to any outcome, either business or user-oriented. Everyone would emerge with a list of features to build and then dole them out to the product managers. Product managers then were responsible for estimating. After reporting estimates back, they would then plan the budget to organise the roadmap. Goals were set on the leadership level, as well. Every part of the company was measuring something and yet, the company was not meeting its goals for the past years.
The issues detected were a few. The leadership team was prioritising the work itself, based on what it thought it was right to build rather than on feedback by customers. It was reacting to the customers that screamed the loudest instead of evaluating whether those requests matched the strategic objectives. The morale was low.
A good company strategy should be made up of two parts: the operational framework, or how to keep the day-to-day activities of a company moving; and the strategic framework, or how the company realises the vision through product and service deployment in the market.
Trying budgeting, strategy, and product development to an artificial yearly time cycle only creates a lack of focus and follow-through. Think of the major pieces of work you do that are actually bets.
Spotify operates using something called DIBBs (Data, Insights, Beliefs, and Bets). The concept of thinking of initiatives as bets is powerful because it sets up a different type of expectation. Spotify sets up an environment in which it's safe to try new things and fail.
Strategies are interconnecting stories told through the organisation.
Agile teams are really good at telling two-to-four-week stories. As you go up in the organisation, you tell stories with longer timespans. Executives are really goodat telling five-year stories, but a team cannot act on a five-year story when they're used to thinking in two-to-four weeks. – Jade Bloom
While executives might be looking at a five-year strategy, middle management is thinking in smaller strategies – yearly or quarterly – bounding teams in a direction that allows them to make decisions on a monthly to weekly basis.
When teams are not sufficiently constrained, they become stuck
They feel like they cannot make a decision because there are too many options – Jade Bloom
Not having the right level of direction lands us in the build trap.
OKRs is a type of strategy deployment used by Google. Hoshin Kanri is a strategy deployment method used by Toyota. Even the military uses strategy deployment with mission command. Setting the direction for each level of an organisation so they can act. In most product organisations there should be four major levels in strategy deployment:
- Vision
- Strategic intent
- Product initiatives
- Options
Is the process of figuring out which direction the company should act. This takes time and focus to craft and maintain. You need to be identifying problems and determining how to organise around solving them at every level. If you are in the C-Suite this should be your top priority.
You must first understand the vision, or where you want to go. Then we can identify problems or obstacles standing in our way.
In Toyota, the continuous improvement framework is called the Improvement Kata. The Kata teaches people in the company how to strategically tackle problems to reach goals (explained in Mike Rother's book Toyota Kata).
Through this act of exploring and identifying problems, you uncover data that is needed to help inform the strategy and vision. Vision is not set solely top-down by management. The entire organisation should be sharing information as they learn about. Bloom calls this information Physics.
The teams should be out there, analysing, testing, and learning and then communicating what they discover back to their peers and their management teams. This is how we set strategy.
This process of communicating data and direction up and down – and across – the organisation is how we maintain alignment.
The company vision sets the direction and provides meaning for everything that follows.
Amazon is an example of a company with a great vision and strategy:
To be Earth's most customer-centric company where customers can find and discover anything they might want to buy online, and endeavors to offer its customers the lowest possible prices
If you are a single-product company, your company's vision is very similar or even the same as your product vision. By keeping an eye on the overall vision, people can make effective decisions about the things that they should and shouldn't pursue. The strategy needs to start at the corporate level, moving through the business lines, and ultimately arriving at the products. At these types of companies, products are just details on how the company vision is manifested. They are the vehicles for value.
A good mission explains why the company exists. A vision explains where the company is going based on that purpose. The best thing a company can do is to combine both the mission and vision in one statement to provide the value proposition of the company – what the company does, why it does it, and how it wins doing that.
Examples of compelling vision statements:
At Bank of America, we are guided by a common purpose to help financial lives better by connecting clients and communities to the resources they need to be successful – Bank of America
Becoming the best global entertainment distribution service, licensing entertainment content around the world, creating markets that are accessible to film-makers, and helping content creators around the world to find a global audience – Netflix
They are short, memorable, and clearly articulated. They don't include fluffy terminology. You do need to focus your company around where you want to concentrate. It's okay to want to be the best on the market or the market leader, but you need to give some context on how. Leaders need to spend time communicating their vision, you must tell a story.
The difficult part is connecting the vision back to the company's operations. This is where company leaders must specify strategic intents.
This is how you intent to reach that vision changes as your company matures and develops. Strategic intents communicate the company's current areas of focus that help realise the vision.
When determining the intents, the C-Suite of the company should ask "what is the most important thing we can do to reach our vision, based on where we are now?" These should not be laundry list of desires or goals, they just need to be a few key things that need to happen to make a big leap forward.
Instead of dictating these solutions down to the teams, leadership should focus on creating strategic intents. Getting the right level and number of intents is very important. Too many higher-level goals, and you are back to peanut buttering. One intent is usually good for a small company, and three are plenty for a large organisation.
Strategic intents are about the whole company, not just the product solution.
Product initiatives translate the business goals into the problems that we will solve with our product. The product initiatives answer how?
A product initiative could be something like the following:
As a Netflix subscriber, I want to be able to watch Netflix anywhere, with anyone, comfortably.
There are many solutions (options) to solve this problem, and they have to be aligned to this product initiative.
Options are your bets, sometimes the solution will be readily apparent, but other times you need to experiment to find the solution.
Product initiatives set the direction for the product teams to explore options.
Companies often have trouble aligning around a product vision. Often they end up with too many products and no coherent vision. Building one-off products to satisfy individual customer requests, failing to address a wider audience. Too many people, too little direction, and no holistic approach. Often revealing a bigger issue, the lack of an overall vision.
Although delivering multiple features and delivering value is a good thing, we need something to tie it all together at the top. The product vision communicates why you are building something and what the value proposition is for the customer.
The product vision emerges from experimentation, you need to be careful not to make the product vision too specific. It cannot describe every little feature but should include more of the main capabilities it enables for the user.
An example for a vision at Marketly:
We help marketing professionals to advance their skills by allowing them to understand their current competencies, easily find the most relevant classes to get to the next level, and then learn the skills they need in the most engaging and digestible fashion, from world-class teaches in the marketing space.
The VP of Product should make sure everyone is aligned with this holistic vision.
Companies with more than one product wrap their products under what is called a product portfolio.
The CPO is responsible for setting the direction and overseeing the product portfolio. The CPO answers these questions for their team:
- How do all of our products work as a system to provide value to our customers?
- What unique value does each of the product lines offer that makes this a compelling system?
- What overall values and guidelines should we consider when deciding on new product solutions?
- What should we stop doing or building because it does not serve this vision?
Leaders often complain that they don't have time to innovate. Usually, this is due to poor capacity planning and strategy creation. It's not that you don't have time to innovate; it's that you are not making time to innovate. You are going to need to say no to some things.
We believe that by increasing the amount of content in our site in key areas of interest, we can acquire more individual users and retain existing users, resulting in a potential revenue increase of $2,6555,000 per month from individual users.
Options to explore:
- Easier and faster ways for teachers to create courses
- Feedback loops for teachers on areas of interest for students
- Outreach to new teachers who can create courses in areas of interest
Usually, when we think about processes, we focus more on the act of developing software than we do about building the right software. This is the build trap.
The process by which we uncover the right solutions to build is called the Product Kata.
The Product Kata is highly inspired by the Toyota Kata, which was a Continuous Improvement framework that creates the habit of improving by focusing on learning. It teaches you how to analyse problems and then create small experiments to solve them. Every team member is responsible for improving the company's processes.
- Understand the direction. What challenge are you striving to meet?
- Grasp the current condition. What is the process's current pattern?
- Establish the next target condition. What pattern do you want to have next?
- Plan-do-check-act (cycle) toward the target condition. The step-by-step discovery process between where you are and where you want to be next.
Management will set the challenge while teams grasp the current condition and establish target conditions.
Next, you follow the Coaching Kata to plan the steps to get to the next target condition. The coach is a team member who asks the following questions during every meeting. The whole team answers and plans the work. The questions are the following:
- What is the target condition?
- What is the actual condition?
Reflect on the last step taken. You don't actually know what the result of a step will be!
- What was your last step?
- What did you expect?
- What actually happened?
- What did you learn?
- What obstacles do you think are preventing you from reaching the target condition? Which *one are you addressing now?
- What is your next step? (next plan-do-check-act cycle / experiment) What do you expect?
- When can we go and see what we have learned from taking that step?
Reflect on the last step taken. You don't actually know what the result of a step will be!
- What was your last step?
- What did you expect?
- What actually happened?
- What did you learn?
Now the process applied to Product is what is called Product kata and the continuous product improvement
- Company goal, product KPI, future state.
- What are the users doing now? (planning)
- What is the first little goal?
- User research, product experiments (experimenting)
The first task is to get to the product initiative and determine what problems you can solve to further the strategic intent. We then need to break the success metrics into something we can measure on a shorter time scale. We call this the team goal, and it's how we measure the success of the option. The team goal should be something we can measure after every release.
After we have set the goal, we begin walking the Product Kata:
- What is the goal?
- Where are we now in relation to that goal?
- What is the biggest problem or obstacle standing in the way of me reaching that goal?
- How do I try to solve that problem?
- What do I expect to happen (hypothesis)?
- What actually happened, and what did we learn?
We answer questions one through four to figure out how to plan our next move as a team. Five and six, determine whether to go back to the beginning for the next round. These questions take us to problem exploration, solution exploration and solution optimisation.
When considering whether to experiment around a particular solution
Don't spend your time overdesigning and creating unique, innovative solutions for things that are not core to your value proposition. If someone has already solved that problem with a best practice, learn from that, implement their solutions, gather data to determine if it's successful in your situation, and then iterate. Reserve your time and energy for the things that will make or break your value proposition. – Zappos former head of UZ, Brian Kalma
When the problem that you are solving is core to your value proposition, take a step back and don't rush into the first solution. The best thing you can do at the experimentation stage is to kill the bad ideas! The fewer, the better.
Metrics tell you how healthy is your product, and ultimately, your business.
Unfortunately, teams end up measuring vanity metrics. Goals that look shiny and impressive because they always get bigger. For example, people get excited by the number of users they have on their product, the daily page views, or how many logins their system has. These metrics do not cause you to change your behavior or priorities.
You can easily turn a vanity metric into an actionable metric by adding a time component to it. For example, do you have more users this month than the last? Consider the meaning behind the metrics and how they help inform your decisions and understanding.
Additionally, product teams often measure output-oriented metrics such as the number of features shipped, story points complete or user stories worked on. Although these are good productivity metrics, these are not product metrics. They cannot tie the results of product development back to the business.
There are many product frameworks available to help you think about the appropriate product goals.
Pirate metrics were created by Dave McClure, founder of 500 Startups, to talk about the life cycle of users through your product. Thinking of it as a funnel. Users finding your product is acquisition; users having a great first experience is activation; keeping users returning to your product is called retention; users recommending others because they love your product is referral; and finally, users paying for your product because they see value in it is revenue. Put it all together AARRR – Pirate metrics.
Acquisition is that users land on your site and sign up. Activation is when someone takes the first step with your product toward having a great experience. This path works for consumer products with a freemium attribute. If you are a B2B product with a sales team, you generate revenue before users have activation. You can swap the order of these to match your product's flow.
As this works as a funnel, you can easily calculate the conversion through each step.
Understanding how many people are in each phase of the funnel also lets you target those cohorts and figure out how to move them into the next one.
Although Pirate Metrics is popular, some people saw the flaw that it did not talk about user satisfaction. Kerry Rodden, a Googler, created the HEART metrics for this.
HEART metrics measure happiness, engagement, adoption, retention, and task success. Adoption is similar to activation in Pirate Metrics because you are talking about someone using the product for the first time. Retention is the same as in Pirate Metrics. Happiness is a measure of how satisfied the user is with the product. Engagement is a measure of how often users interact with the product. Task success measures how easy it is for a user to accomplish what they were meant to with the product.
Retention is a lagging indicator. It will be months before you have solid data to show that people stayed with you. That's why we also need to measure leading indicators such as activation, happiness, and engagement. Leading indicators tell us whether we're on our way to achieving those lagging indicators like retention. In the case of retention, you can qualify what keeps people retained, for example, happiness and usage of the product.
One of the first things every company should do is to implement a metrics platform. Amplitude, Pendo.ai, Mixpanel, Intercom, and Google Analytics are all data platforms, and they all enable product managers to make well-informed decisions.
You won't be able to set success metrics without investigating the problem. This is why we first need problem exploration.
Although data analysis is important, it can't tell the entire story. So, it's essential that we all go talk to actual humans and get to the heart of their problems.
Giff Constable created an entire book called Talking to Humans. User research, observations, surveys, and customer feedback are all tools that you can harness to better explore the problem from a user standpoint. User research, in this case, is not to be mistaken for usability testing, which involves showing a prototype or website and directing people to complete actions. There, you are learning whether they can use and navigate the solution easily, not whether the solution actually solves the problem. This type of research is called evaluative.
Problem-based user research is generative research, meaning that its purpose is to find the problem you want to solve. Going to the source of the customer's problem and understanding the context around it. Trying to identify the pain point and the root cause of the problem.
It's easy to fall into the trap of solving problems before you find their root causes. We're all prone to problem solve, even if we don't know what the problem is.
It's also easy to become attached to solution ideas. "Nobody wants to hear their baby is ugly". The way around this is not to get too attached. Kill the bad ideas before they take up too much time and energy from the teams and before you get hooked on them. Instead, fall in love with the problem you are solving.
By getting into the mindset of solving problems early, you allow much more time to build the right thing, because you're not wasting time chasing after the wrong things.
In many companies, it's difficult, or even impossible, to talk to the customer, usually due to corporate bureaucracy. In a consumer industry, you can usually reach out to friends of friends who use the product or have the right background. In a B2B environment, you can work with the sales or account managers to have them be your research spies – asking the questions you might need to know during their sales calls or follow-up meetings.
You have to remember that is not the customer's job to solve their own problems. It's your job to ask them the right questions.
Companies often confuse the building to learn and building to earn. Experimentation is all about building to learn. Experiments should not be designed to last for a long time, they are meant to prove whether a hypothesis is true or false, and, in software, we want to do this as quickly as possible.
When we use an MVP only to get a feature out quicker, we're usually cutting corners on a great experience in the process. We sacrifice the amount we can learn from. The most important piece of the MVP is the learning, "the minimum amount of effort to learn".
Experiments are designed to help companies learn faster. We are not creating stable, robust, and scalable products.
The Product Kata is great for this, it always asks the question "What do you need to learn next?".
Concierge, Wizard of Oz, and concept testing are three examples of solution experiments. With any experiment, it is important to think of how you will end it. Setting expectations on experiments with your customers is key to keeping them happy. Explain to them why you are testing, when and how the experiement will end, and what you plan to do next. Communication is key to a successful experimentation process.
Concierge experiments deliver the end result to your client manually, but they do not look like the final solution at all. Your customers will understand that you're doing it manually and that it's not automated. Concierge experiments are particularly interesting for B2B companies because this is how many of these companies got started, by taking on the work for the customers and then later automating it.
These experiments don't scale, given that it's labor-intensive. You should conduct these experiments with just enough users so that you can stay in regular contact with them, get plenty of feedback.
This is a method you can use for reaching a broader audience for feedback. It looks and feels like a real, finished product. Customers don't know that, on the backend, it's all manual. This is a great technique when you are looking for feedback at scale.
Companies are tempted to leave Wizard of Oz experiments up for a long time because they look real to the customers. This is not wise because it is still manual on the backend.
Wizard of Oz can be combined with techniques such as A/B testing. Although, you wouldn't want to use A/B testing in two instances: if you were very unsure about your solution direction or if you did not have enough traffic on those pages to have significance.
It focuses more on high-touch interaction with the customer. You try to demonstrate or show concepts to the user to gauge their feedback. From landing pages and low-fidelity wireframes to higher-fidelity prototypes or videos of how the service might play out. The idea is to pitch the solution idea in the fastest, lightest way possible to convey the message.
In many early-stage companies, concept testing is the way they get early sales or capital.
The mentioned tools are used for higher amounts of uncertainty and, thus, larger risk in your solution ideas. In a case where the team knows the problem and the solution, it's time to implement it. There is no need for up-front testing.
You should still be building to learn instead of rushing into a complete solution, but there are other tools you can harness, such as prototypes.
Prototypes are the most popular tool for testing. They don't require any code, and there are many software products out there that can help you link screens together to make the flow feel real. Prototypes don't make sense when you need to validate the problem. You'd be spinning your wheels creating shiny designs that look great but don't help you to learn what you need to learn.
If we take too long to get feedback, we not only waste money but also waste time. The opportunity cost of building the wrong thing is too high.
You should do it. If people can't figure out how to use tools, that's on you, not them. Internal tools are often neglected, but they still matter to the company. They need to be treated the same way as any other product.
After the direction is set for the product vision, it's important to make sure everyone understands the context and work that needs to be done. Story mapping and North Star documents are two ways to help teams find alignment around the vision.
A North Star document explains the product in a way that can be visualised by the entire team and company. This includes the problem it is solving, the proposed solution, the solution factors that matter for success, and the outcomes the product will result in.
North Stars are great for providing context to a wide audience. They should be evolved over time, as you learn more about your product. This is not an action plan, it does not include how the team will be building the product. That is where story mapping comes in.
Story mapping is a technique created by the product management veteran and consultant Jeff Patton, to make sure people understood the work and to prioritise the first release. It helps teams break down their work and align around goals. "It's purpose is to help the team communicate about their work and what needs to get done to deliver value". This includes breaking down each desired action from the user standpoint.
Prioritisation is a top issue for most product managers. There are many frameworks out there that will help you prioritise, like benefits mapping, Kano models or Cost of Delay.
In the book The Principles of Product Development Flow, Don Reinersten talks about the importance of the Cost of Delay. Cost of Delay is a numeric value that describes the impact of time on the outcomes you hope to achieve. It combines urgency and value so that you can measure impact and prioritise what you should be doing first.
Consider the trade-offs between the amount of value you can capture with the scope of the release and the time it takes to get it out the door. It's an optimisiation problem. You want to reduce scope enough so that you can capture the maximum value in the right time. If you wait too long because you overscoped the release, you lose the money you could have been making. Worse, a competitor could swoop in and steal your market. On the flip side, you don't want to release something that is terrible and provides minimal benefit to the user in order to get it out early.
You should discuss each feature or feature component in terms of urgency and value. If it is high urgency, that means that ever moment you do not ship that feature to customers, you are losing out an opportunity to hit your goal. High value is about solving the strongest problems or desires for the customer.. Learn more, head to Black Swan Farming.
When teams create their Definition of Done, it's usually around finishing building features required to ship a product. It sets the wrong expectations about what a finished feature is. We are done developing or iterating on a feature only when it has reached its goals. We need to measure the outcomes.
Teams should set the success criteria before the launch while measuring and iterating until they reach it. Being able to talk to customers, oriented to outcomes, and with the required space provided by the leadership team to figure out how to achieve those outcomes. These are the marks of a product-led company. Culture, policies, and structure are the things that really set a company apart to thrive in product management.
The product-led organisation is characterised by a culture that understands and organises around outcomes over outputs, including a company cadence that revolves around evaluating its strategy in accordance to meeting outcomes. In product-led organisations, people are rewarded for learning and achieving goals. Management encourages product teams to get close to their customers, and product management is seen as a critical function that furthers the business.
Kodak made good strides in trying to innovate, but its organisation prevented it from doing so. The company was reactive than strategic, waiting too long to respond to a threat. When people work in silos, innovation often happens in a separated place without the proper resources to fully execute on what is being discovered. The fate faced by Kodak can be avoided by adopting a product-led mindset.
You can be making an effort to understand customers and to conduct good research, but without the organisation to sustain it, the efforts are too little, too late. You need to become a product-led organisation, both in mentality and in practice.
Companies stuck in the build trap are usually not patient enough to see outcomes emerge, so they instead measure progress by the number of features shipped.
Leaders will say that they want to achieve results, but at the end of the day, they still measure success by features shipped. People want to feel like they are accomplishing things. Checking off the boxes of finished work feels good, but we need to remember that this is not the only measure of success. It's important to have a cadence of communciation that shows progress at every level of the organisation, tailored to each specific audience.
Visibility in organisations is absolutely key. The more leaders can understand where teams are, the more they will step back and let the team execute. If you keep things transparent, you will have more freedom to become autonomous. Companies tend to fall into bad habits because they have not figured out how to consistently communicate progress in the form of outcomes. When leaders do not see progress toward goals, they quickly resort to their old ways.
There are a few core meetings to evaluate progress:
- Quarterly business review: The senior leadership team should discuss progress toward the strategic intents and outcomes of a financial nature. Reviewing revenue for the quarter, churn of customers, and costs associated with the development of operations. The CPO and their VPs of product are responsible for communicating how the outcomes of product initiatives have furthered strategic intents. This is not the place to prioritise new product initiatives or to go into detail on them. That is what the product initiative review is for.
- Product initiative review: This is a quarterly meeting dedicated for the product development side of the house – CPO, CTO, design leaders, VPs of Product and product managers. Here you review the progress of the options against the product initiatives and adjust our strategy accordingly. This is the place for product managers to talk about the results of preliminary experimentation. New product initiatives can be introduced in this meeting for feedback and buy-in.
- Release reviews: These provide the opportunity for teams to show off the hard work they have done and to talk about success metrics. These should happen monthly, before features go out, to showcase what is in the pipeline to be released. You should be communicating only what we know is going to ship, not the experiments or research being conducted. Executives can join to see what is being shipped out to customers. This can also be a place to communicate the roadmaps internally so other departments and the executive team are aware.
Instead of thinking of roadmaps as a Gantt chart, you should view them as an explanation of strategy and the current stage of your product. To do this, the product roadmap should be updated constantly (Living Roadmaps). You should design your communication to match your audience. A great book on how to set a roadmap is the book Product Roadmaps Relaunched.
Roadmaps consist of a few key parts:
- The theme
- Hypothesis
- Goals and success metrics
- Stage development
- Any important milestones
You should align your company around certain terminology to describe stages of development. We can use these four phases:
- Experiment: At this stage we want to understand the problem and to determine whether it's worth solving. Teams are conducting problem exploration and solution exploration activities. No production code is being created.
- Alpha: Stage to find out if the proposed solution is desirable to the customers. Production code gets built and is live for a small set of users. These users understand that they are getting early access to a feature that might change or be killed.
- Beta: Stage to find out if the solution is scalable, from a technical standpoint.
- Generally Available (GA): The solution is widely available to all of our clients. Sales teams can talk openly about GA products.
Poorly-constructed roadmaps are the source of much tension between product and sales.
Although communicating status can be scary, given the variable nature of software development, it's also necessary. Product management enables the sales strategy. Sales still needs something to sell. Creating working agreements and roadmaps that can be communicated to customers is key to developing a good relationship between product and sales.
As product teams scale to more than a few teams, keeping track of progress, goals, and processes becomes a challenge. Teams need to focus on growing their product, and operations work becomes too much of a distraction. At Marketly they ended up implementing a product operations team, run by a chief of staff who reported to the CPO. This was a very small team (two people) to help streamline operations and reporting. This allowed product people to focus on what they were good at, while product operations helped them to make ifnormed decisions, by surfacing up those reports.
This team was responsible for:
- Collecting data on progress toward goals and outcomes across teams.
- Report on goals, outcomes, roadmaps, progress, capacity, and costs.
- Set up and maintain a product analytics platform to report on product engagement metrics.
- Standardise product progresses that go across teams, such as strategy cadences, experimentation tracking and feedback, documentaiton on product features, collecting data, setting goals, creating and maintaining roadmaps, and sales enablement.
- Organise and run critical product meetings for strategy creation, strategy deployment and releases.
- Conduct any coaching or training for the product teams.
The point of this team is not to dictate how the members of a team work together to build the product, but instead to create the citeria for inputs and outputs of the work. They are not dictating whether a team can talk to users. They are creating systems that help teams figure out which users to target for their experimentation.
The product operations team should be made up a combination of project managers and product people. "Success for you would be automating away your team". This is not a team that is meant to be large. It's an efficiency engine dedicated to automating, streamlining, and optimising.
To often Product Managers say "It doesn't matter what the goal is. We just have to deliver this feature". They are being forced into the build trap by company policy. Shipping product instead of learning or solving problems for customers is what gets you into the build trap. People become afraid to try anything new. The best advice is to push back.
If you don't have the seniority, you can still try to change the minds of the people who can bring those messages up the chain. Talk to your bosses about what success really means. Define your metrics for when you know you will be done. Always come with data.
Most sales teams are held accountable to selling, signing the contracts and bringing in the revenue. Many teams overpromise in order to make their commission numbers.
Imagine being in company where the Sales team oversold so much the development team has to run two years behind. Customers wold get angry and this would lead to high churn. Sales teams would target the wrong customers in order to make numbers. These customers would leave quickly.
We want to incentivise sales teams to keep selling, but adjusting the components of their salary so that their livelihood does not depend too mucho n the commision percentages can help to mitigate this risk. Trying retention numbers to their success metrics.
There may not be enough safety in the organisation to fail and learn. Product managers need a certain amount of trust from the organisation to have room to explore different options. Teams are going to have tro try some perceivaly wild stuff. If they are not allowed to explore these weird paths, they will never push for the status quo.
Remember, it is not a success if you fail and o not learn. Learning should be at the core of every product-led organisation. It should be what drives us.
It is also better to fail in smaller ways earlier, rather than spending all the time and money failing a publickly large way.
Many companies talk about how they want their people to be innovative and how they want to create crazy new products, but there has to be an understanding that it's safe to fail in order to get innovation. The irony is that experimentation is the ultimate risk-management strategy because when you experiment early, you can preent failure.
Taking 10 years to fail, slowly burning through cash and never getting anyware is more problematic than allowing for smaller failures along the way.
If you adopt a great product mindset and you give people the freedom to fail, what you're doing is allowing them to fail quickly, quietly, and at a lower cost because they're testing things early. That's the type of failure you want to encourage. That's the type of failure from which we can recover.
Leaders who give people the room to do that see the best results and avoid the build trap. It's also the leader's job to give people boundaries within which to operate. There are many different ways to create boundaries. You can segment your user base into populations for Alpha and Beta testing, start with small representative population, learn from them and then expand. Allows you to contain the rollback if the product doesn't work.
At some corporations if you don't deliver what's on the roadmap you don't get as much funding next year. That means that if a team finds a way to build a product cheaper, or finds that the product shouldn't be built at all, the team will build it anyway because they will be penalised if they don't spend all their money.
It's far wiser to look at funding product development like a venture capitalist (VC). "This is where we are. These are our next goals. We need this much money to get to those goals."
In addition to a culture that rewards and promotes learning, you need a culture that focuses on the customer. To put yourself into your customer's shoes ask "what would make my customers happy and move our business forward?" Product management is about value exchange. Being customer-centric allows you to figure out what products and services will fulfill that value on the customer side.
Let your teams talk to and see your customers in action. Being customer-centric means that you know the most important thing you can do to create great products is to deeply understand your customers. This is also the core of what it means to be product-led.
When companies try being customer-led, one of the biggest mistakes they make in the transition is having leadership think that it's everyone else's job to change instead of theirs.
I needed to learn about humility. I learned that my role was not that of the big idea generator but that the bad idea terminator.
As I moved into more senior roles, I learned that having a good strategic framework could make or break a company.
People will get in the way of a good product every time. If it doesn't meet the agendas of senior stakeholders, good ideas can be squashed. To mitigate that risk, you need to deeploy understand what motivates people and to know how you can address their personal motivations by introducing information and data that wins them over.
One of the quickest ways to kil the spirit of a great employee is to put them in an environment where they can't succeed. Even good product managers become tired of waking up and going to war every day.
The fundamental criterion for building a product is that the product solves a problem for the user.
- Who came up with the last feature or product idea you built?
- What was the last product you decided to kill?
- When was the last time you talked with your customers?
- What is your goal?
- What are you currently working on?
- What are your product managers like?