• Those comfortable with discomfort will come out ahead.

• Stop thinking in roles. Think in functions. What stops an engineer from running product management functions, or a PM from owning design? Experts will still be relevant, but teams can be faster and more effective, especially if they are thin.

• Surprisingly few people actually know what they do in their companies, at least from everyone I talk to. Most are running on instinct.

• The pace of new tools and methods is genuinely insane. Find your people who actually run things, and learn what’s worth trying from them. LinkedIn and Twitter are mostly noise and flexing. Don’t buy your sellers’ messaging (the ones who build the tools you buy).

• Regardless of how models evolve, I still keep four different products open for different tasks. Are they getting worse, or am I just getting AI-lazy?

• What Palantir calls the “frontier deployed engineer” should be the standard model: ship it, fix it, adjust it, then generalize. Palantir had the advantage of a configurable platform, but that’s no excuse to wait before scaling.

• Non-technical users and clients are far more lost than the tech crowd; most interactions feel like ChatGPT’s launch day all over again. Radical as it sounds, getting something in their hands fast is often more useful than explaining what’s possible.

• It’s still unclear whether companies are chasing optimization or genuinely new opportunities. B2B conversations are increasingly exploratory and consultative, helping them figure out what even fits.

• Opaque pricing for AI tools is wearing me down. I get my first result, start refining, and my credits are gone. Time-to-value should be your north star.

• It’s chaos. And the skill that matters most right now is learning to manage it.

• I was not impressed by the metaverse and web3 era. I'm not overhyped about AI either. But I do believe we're far from tapping what we can practically do with LLMs; we still have engineering and experience capacity for improvements.

• For now, I prefer hybrid AI solutions; humans in the loop, not out of it.

• People won't use large models and chat interfaces for everything. When running common tasks, people want to be fast and think less. "Don't make me think" was the mantra; funny how quickly that got forgotten.

On Product Managers

Product managers sit at an uncomfortable intersection right now, and that’s exactly where they should be. The role was already under pressure before AI accelerated everything. Now the margin for vagueness is gone. The PMs who thrive will be the ones who stop hiding behind process and start owning outcomes. Here’s what I think that looks like in practice:

• Those who are strong in non-ticket work will stay relevant and empowered.

• Anyone who genuinely cares about creating value should be excited right now.

• If you lacked technical or design skills before, there’s no excuse anymore.

• For certain product types or functionalities, designers and engineers will assume this role entirely.

• Managing chaos with an organizational mindset will be a core differentiator.

• Being disconnected from engineers over internal politics is a real liability, and frankly, a shame.

• Time to rethink how we split our hours between learning, experimenting, delivering, and packaging.

• Vibe-coded prototypes are great for communicating ideas or sparking real customer conversations. But they are prototypes. Don’t wait to ship one unless you already have an internal pipeline behind it.

Because the same question is not just about Engineers. It touches designers, PMs, and the entire way we build product teams. Even if some people have verdicted the disappearance of the PMs before the one of the Engineers…

So, let’s break it down to what AI changes in the PM role in my opinion, based on my interactions and personal experiences so far.

New team superpowers, new dynamics

What is changing is the way teams are working, and the skillset their members have. So let’s see the close collaborators of a PM, forming the Product Trio:

• Engineers now have a much smaller learning curve when it comes to understanding business needs. They can prototype faster, closer to users, even live. They are able to optimize solutions based on business context much earlier in the process. But they will still struggle with handling uncertainty about what needs to be built and why. Additionally, someone needs to build the infrastructure for using the right models and finding the balance between building functions with clear outputs and using the creativity of AI to create a more personalized feeling for users, more like architects. So, the context switch cost remains, it’s the quality of the output that can be better, with smaller teams, if done right.

• Designers are now able to automate and simulate user research, even generate personas that represent mass market behaviors better than traditional interviews. If the goal is scale, there is no better input today than what LLMs can generate, as they are trained on mass data. If the goal is differentiation, they have to think outside the box, and use LLMs to see what mainstream ideas look like. Their value remains on designing for the human interaction, which cannot be left on LLMs:

  • working on the brand and the aesthetics

  • focusing on the clarity of the user journey

  • designing usable prototypes with no-code tools, for quicker validation

  • building good experiments

  • using LLMs for completeness and design QA, especially on edge cases they haven’t thought about

What about the PMs now?

What’s left for the PMs depends on the phase and current state of the team. A good PM should still be the person who makes the team super productive and fast. The one who finds the invisible glue that holds things together. Some areas where PMs can still create huge value:

• Project Management. Few people enjoy it, but no one can operate without milestones and proper resource management. Someone has to take responsibility and do it better than before.

• Bringing Clarity. Teams can only have clarity if leadership has clarity first. Cross-team alignment has always been hard and it will only get harder as AI speeds everything up.

• Vision and Forward Thinking. When execution becomes a commodity, thinking becomes the differentiator. PMs need to constantly work on their strategic thinking, spotting opportunities, connecting dots, and shaping what is next.

• Internal Automations. When a role is missing or underperforming, someone has to recognize it early and use AI to fill the gap. Whether it is Customer Success, Marketing, or Ops, someone needs to implement a fix and explain its impact to leadership.

• Filling the Gaps. If designers or engineers are unable to meet the new expectations of speed and quality, PMs have to step in, coach them, or partially bridge the gap themselves. The quality of their contribution, especially to better communicate ideas, can be increased radically with the usage of AI tools.

What makes a Good PM in this new reality

Yes, we will need less and on later stage the PMs. And the PMs have to step up with more agency and more creativity in this new era. Some qualities will matter even more:

• Aesthetics and Taste: knowing when something is not just functional but also appealing

• Strategic Mind and Clarity: being able to make good decisions and help others do the same

• 360-Degree Business Sense: understanding how product, marketing, operations, and growth fit together

• Coaching and Leadership: inspiring people to do better, not just managing tasks

• Communication skills. No explaination needed. At least we can write better emails now.

It’s a bright new era, for an evolving role

PMs still need agency, good judgment, and a urge for impact. But now they also have new tools to break any existing silos; The barriers that used to slow down teams like slow research, expensive prototyping, or lack of visual design can now be overcome by a good PM who knows how to use AI.

The next generation of PMs needs to think and act more like intrapreneurs inside their companies. This is something I will write about more, especially now that I have crossed over to the founder side and have some lessons to share.

A PM should be hired when you need someone dedicated to product responsibilities you once managed yourself but can no longer handle alone. Until then, consider bringing in a trusted Product Leader to help guide your company through its transformation.

What to do instead

Regarding managing your team, you can focus on the following areas:

• Option 1: Learn some basic product management tools and try to fix the basics of your organization. If you can’t do planning and you call for an urgent meeting every time you have an idea, the PM won’t solve your problem. You should learn the following tools:

  • RICE for prioritization. You should be able to put your thoughts into a priority, with some criteria, before you go and disrupt your team. It’s important for you as well.

  • Shape up, or any other planning framework. Learn how you can use and empower your teams with some early thinking and collaboration, and then give them the time they need to deliver big wins. That doesn’t mean you should top progressive releases, that you aim for clear and bigger value.

  • Think with user journeys, to have a complete picture without breaking the experience. The first days of a Sprint, will help you map and work with your teams to prioritize based on complete experiences.

• Option 2: Use a product leader as a consultant first. Engage a short-term product consultant to provide essential guidance without the full-time commitment, particularly useful in the early stages.

Regarding your product design and planning, you may fall under the following categories

• Case 1: For Consumer Products - If you’re consumer-focused, bring in a Product Designer as early as possible. If a full-time designer isn’t feasible, consider a contract designer for key planning sessions (like those in Shape Up) to guide high-level product design.

• Case 2: For Sales-Driven (B2B) Products - Build a usable product from the start, with minimal reliance on training or documentation. Ask yourself: would you use your product if it weren’t mandatory? Even if end-users aren’t the primary audience, usability will drive long-term benefits. Avoid excessive product debt, and consult Product-Led Growth (PLG) resources to guide this process.

• Case 3: For Enterprise-Focused Products - Focus on creating a flexible platform that can adapt to diverse client needs. Be part of the team that prioritize features that bring high customer value and balance with company revenue, and ensure you have strong technical direction from an experienced architect or engineering lead.

For any approach, remember to price services separately from the core product. Product development should not subsidize ongoing service needs, as this will overburden your development team, leading to burnout and poorer product quality. If you want to be price-competitive, explain upfront the discounts you are offering on that level.

When to hire a PM

There is no common rule on when you should hire a PM. You may read Lenny’s analysis on when well-known startups hired their first PM, and why. Consider hiring a PM if:

1. You cannot find a product market fit, and you need someone to help you with it.

2. You want to transform from a sales-driven to a product-led one. This is the most challenging, and you need a Product Leader with experience. But most importantly, you have to back it up all in.

3. Break your product into domains and allow it to scale faster, because you use more resources.

4. You want to launch a new product or launch in a new market, and you need to hand over your current product to someone else.

5. You understand the main value the product creates, but you need someone to take care of all the details based on experience (e.g. onboarding, etc.).

6. You feel your product is getting noisy and bloated as time passes, and you don’t know what is used and why.

Onboarding your first PM

When you bring in a PM, treat them as a strategic partner, not just a task executor. PMs bring valuable expertise and require a collaborative environment to thrive. They are not project or delivery managers, nor personal assistants—they are strategic assets whose success depends on clear onboarding, alignment of expectations, and regular communication. You can read my relevant article for onboarding your PMs, to facilitate your PM’s onboarding.

Reasons to design

You may already know that creating an application doodle on a whiteboard during a PM interview gives you more credit as a candidate. I hope your design skills are not limited to the interview process, there are many other reasons you may want to design on a regular basis as a Product Manager.

1. Shortage of design resources. Under the notion of a Product Trio, you may have heard that a good designer should be the partner you need to bring your ideas to life. I agree with that idea, and there is no better thing than working with a good Product Designer, as it is to work with a good Engineering Manager. However, expectations don’t always meet reality, as there is frequently a shortage of design resources, especially for startups. Thus, when you want to communicate an idea, you may wait for the next availability of your design resources, or you create an early design either to get alignment or early validation of your ideas.

2. Create clarity, reduce complexity. There is no better way of realizing the complexity of what you describe through documents unless you try to design it. This is the moment that you realize that a nice-looking idea may be more complex than you initially thought, or that a simple idea may have different implementations. Personally, for big releases, I regularly create some draft designs and I iterate between the document and the design, so I improve my clarity and simplify what I suggest.

3. Bridge communication gaps. Hopefully, you won't need to code your solution; If you want to test your prototype, you have faster and more efficient ways to create alignment on what you have in mind. Trying to get closer to the final state of the deliverable by designing it will help you have a better view of what you expect from the product designer and the engineers. You will also realize how better your team are at their craft and that you should trust them, or you may realize that they miss some important details and you have to step in. If you treat your designs as an interface for accelerating your collaboration, and not as imposed requirements because “you know better and you can design too”, you will see improvements on your teamwork. Ideally, this will happen in a workshop-like environment, where all have equal opportunities for contribution.

4. Visual mockups win attention. I have written scenarios, use cases, stories, 1-pagers, 6-pagers, PRDs. I can guarantee, there is no stronger way of promoting your ideas if there is a mock design. I have got the green light for a new concept one month after it was dropped, just because this time I had a flow of screens to present. But if your design is too bad, you may have the opposite outcome. In that case, you may have to work more with your designer, before you communicate it broadly; ask them about their opinion, before you bring up your designs to your audience.

5. Learn from doing. Studying the competition or state of the art applications, and trying to copy their UX for your new feature or product is a great exercise that keeps you fit, about your product sense. There is no better way to realize why you like a product than trying to design similar experiences for your case.

6. Do better QA and elevate your standards. When you try to design, you pay attention to the details that you didn't before. The location of the timestamp, the header and the subheader, the single vs multi selections. Then, it is easier for you to find deficiencies on your upcoming releases, even from the designing phase.

How to develop your design skills

You should realize yourself how design may help you with Product Management. Lately, it is easier than ever to design functional prototypes, and I don’t refer to AI-generated wireframes; I prefer having control of what you design and why, and of course you may run iterations with GenAI input as well.

1. Choose a tool. Find the tool that fits you better. My advice is to learn Figma. It has a learning curve, not as bad as the Adobe products, but if you learn to build prototype flows, it's a great skill you will never regret.

2. Reuse the design system. Use your team’s design system to speed up your process, and not confuse the audience by redefining the whole UI and UX. If you learn Figma, there is a big chance your Design Team is already using it, so your life will be easier.

3. Use templates. Search on the Figma community for templates, in case you need to cover a new flow not covered by the design system. Copy the components you like and reuse them.

4. Use collage. If you don't have the luxury of time to develop, use collage, with screenshots from your favorite and most relevant applications. In that case it is useful to create flows. If you are even on an earlier stage, you may use Figjams showing how different users would navigate through different screens.

5. The copy is crucial. Pay attention to the copy of your designs. Your audience will focus more on what you write than how it looks.

6. Keep your team in the loop. Get feedback and advice from your design team, while you are honest with them that they will redesign everything from scratch, or keep the ideas they like. Also, clarify to your internal stakeholders that this is your work, not designers’. Be honest with your audience about the goal of your designs, and insist that this is a way to create clarity and get early feedback. Don't try to sell that you are a designer.

7. For big asks, go with the team. If you are a mature team, go to a design sprint, to balance your creativity with team work and get the maximum from your team. But not everyone team has this “luxury” (we may discuss this paradox on another post).

8. Choose when you go with wireframes. If you feel that the design of the product is important, you should stick to wireframes with emphasis on the flow and the copy. For example, there is no reason trying to design the website yourself.

Designing for products without UI

And where come the edge cases? What happens if I design a non-UI product, or an AI one? In that case, I can suggest the following tools:

1. Use a service design blueprint to describe the whole experience. There is interaction with your website or with an email, even in that case. You may want to create a Figjam to address it.

2. Emphasize the copy and the flow, trying to expose the value of what you are building. Choose a scenario that makes sense for your business, and make it look like a demo for a keynote presentation, a newsletter or your website. Work backward and think how your demo will impress your audience and will pass the message to the audience, without losing sight of the feasibility.

What about Discovery?

In my career, I have seen amazing product designers and engineers with great PM skills. I have seen also PMs with an engineering background and understanding. I have seen however very few PMs with good design skills. You can make this a differentiator in your career. And I hope you will never need it in your day to day track ; but I doubt it that you won't use it if you start realizing how much value in your collaboration you may unlock.

What someone may argue is that the time spent to design could be used for other activities, especially discovery. I see the designing skills of a PM a ways to accelerate the cycles between discovery and early validation, at least to get early feedback, not on a final stage. For B2B companies, it's also a good way to align with internal stakeholders. And as I mentioned already, it's the best way to elevate your design sense so you can better communicate with the product designers.

The goal is not to replace a Product designer, but to decrease your validation and alignment time. If your company provides you with the resources and the systems to achieve that, you should feel lucky. But even in that case, if you ever decided to join or run a startup, you will need design skills for sure.

Product Management sits at the crux of Business, Technology, and User Experience (UX). This unique positioning means that transitioning into a new company, especially from a different industry, requires substantial time for onboarding to learn the new business. This is even more critical in leadership roles, where understanding the specific business language and insights is key to gaining trust and effectiveness.

I have laid out in the past the advantages of joining a fresh business, and definitely, there are transferable traits for a Senior Product person. Thankfully, there are remote options that have increased compared to the past, thus it is easier to find a similar business to join away from your hometown, with the disadvantages of working remotely in a leadership or product management role. However, integrating into a new startup can be a challenging endeavor for Product people. Often, the urgency of startup dynamics means onboarding takes a backseat; New joiners might face undue pressure to self-onboard efficiently, and efforts to understand existing processes can be misinterpreted as criticism. Additionally, finding up-to-date documentation can be a rarity.

In this blog post, I will share practical techniques that I have developed for quickly assimilating business knowledge when joining a new company.

Recognize the state of Product Maturity

If you are the first Product person, look at the CEO; If she is product-aware, she will suggest a proper product onboarding process beforehand, which will include meeting important clients, going through some operations together, sharing her notes for vision and strategy, and setting up some milestones,

If you are in that case, you are lucky. The funny thing is that in most cases when you join a startup people have done not much to help you with onboarding. In that case, you have to create your plan for extracting the required information. This is what this post is talking about.

Step 1 - Create a Customer Journey Map

As soon as possible, collaborate with key stakeholders to map out the customer journey. This exercise not only helps you understand the customer experience in-depth but also fosters collaborative relationships with colleagues from various departments. It’s an excellent way to gain insights into both the product and the company culture. I am using the Design Sprint methodology here (day 1), and it helps a lot. Remember to run this workshop ASAP (first month) so as not to lose momentum.

Step 2 - Find a Go-To Person for Questions

Identify a colleague who is knowledgeable, approachable, and willing to answer your questions. This person can be an invaluable resource in navigating the new environment, providing context, and offering guidance when you encounter challenges or uncertainties. Add regular 1-1s and syncs with her, express your gratitude, and praise her whenever possible.

Step 3 - Document Your Learning Process

As you learn new things, make it a habit to create documentation. This not only helps solidify your understanding but also contributes to the company’s knowledge base, making it easier for future new hires to onboard. Additionally, by the end of your onboarding, you can publish it internally to get feedback while you help any future employee onboarding.

Step 4 - Get access to client info

You should ask to get access to information about the clients. Account managers, briefs from pre-sales or post-sales meetings, and recordings with transcripts. Ideally, you should be assigned to some client meetings. Typically, in the client meetings you should care more about how they use the product, what needs they have, and what problems you solve; that requires some familiarity with the customer and the product.

I prefer to do a study on the domain, map the domain, and read background information before I go into these meetings; I feel I get more value if I have done my study first.

Step 5 - Map the whole picture, not the current state

Commonly, your product doesn’t cover the whole customer path. You should realize the workflows that you cover. For that reason, you can use Porter’s value chain, to understand which part of the customer journey you are addressing.

Step 6 - Aim for Quick Wins

Look for opportunities to make immediate positive impacts. Quick wins not only demonstrate your capability and build trust with your team but also give you a confidence boost as you settle into your new role.

Step 7 - BUT, Align with the Company's Vision

While focusing on quick wins, always keep the company’s long-term vision in mind. Your work should contribute towards this broader goal, ensuring that your efforts are both impactful and aligned with the company’s strategic objectives.

Step 8 - Manage Expectations

You should communicate proactively with your team and manager about what can be realistically achieved in the short and long term. Managing expectations is crucial in maintaining a positive and productive work environment, especially in a dynamic startup setting. Explain that with the help and alignment of other people, you can participate in decision-making and delivery, but you will have to touch base more frequently, align, and prioritize together during the first period.

Step 9 - Prioritize Self-Care and Patience

The onboarding process can be demanding. Remember to take care of yourself – mentally, physically, and emotionally. Patience is key; it takes time to fully integrate into a new role and company. Balancing work with personal well-being is essential for long-term success and job satisfaction.

That’s it, I have been following these techniques when I onboard a new business or product. I hope you find it useful if you are at that stage, and I am open to comments and feedback about your own ways of accelerating your onboarding.

Becoming a Product Manager in Greece back then was a challenge. Startups like Taxibeat and Workable were just getting started, and Skroutz was primarily a price comparison site. The only resources available were books and blog posts from Silicon Valley. I went on a reading spree, applying what I learned as I went. However, finding people to share practical product management insights was a struggle.

Build your toolkit

In 2018, I joined Orfium and discovered that traditional product management norms didn't quite fit. Orfium, a bootstrapped company, had achieved profitability through a significant shift from B2C to B2B enterprise solutions. Their approach involved swift deliveries that, while impactful, didn't easily scale. As we expanded our solutions and teams, I realized that the frameworks that worked for me didn't necessarily work for my team. People tended to rely on the way of working that unlocked this amazing value.

While the intuitive approach worked well initially, it became clear that it couldn't keep pace with the company's growth. At some point, I had to step in to address product and operational challenges, but this time I focused on the outcome of my work rather than prescribing and communicating frameworks.

Some successful framework-related approaches I experimented with included:

1. Organizing a workshop with key stakeholders to define long-term product vision and annual goals, with the team's active participation. I came into the meeting with a suggested solution, but everything was discussed under the broader scope, and the solution was refined collectively.

2. Creating an end-to-end value chain and mapping it according to user jobs-to-be-done to avoid redundancies and clarify product architecture.

3. RICE prioritization helped stakeholders feel heard and included in the process and established trust because of transparency in how decisions were made.

4. When problems started to pop up, it was clear that a broader product strategy was missing. Developing a broader product strategy with a vision type, aligning it with current opportunities, and communicating it formally drove things beyond their current state, and inspired teams.

5. Running a book club instead of asking my team to try frameworks, with the most engaged team members reading a framework book and sharing the knowledge.

6. Aligning teams at both functional and product levels through workflow mapping exercises across multiple products, enabled them to spot inconsistencies and issues they might have missed while working on their individual areas of focus.

My journey with various frameworks taught me several lessons about not using them blindly:

• It's challenging to recommend frameworks in advance to individuals who aren't actively seeking solutions or aren’t deeply curious about product management.

• Frameworks often reflect the unique context of the organizations or environments where they were developed, making them less transferable to different situations.

• Many frameworks are rooted in the success of specific companies with effective business models and an initial user base, which might not apply universally.

• Frameworks seldom document failures or their evolution phases. It would help if you often adapted them to the specific context you're working in.

• Frameworks developed by studying other teams or companies may lack the full picture and often come from a consulting perspective.

• Some frameworks are essential tools to develop specific product management skills but are marketed as structured systems.

In essence, my experience underscores the importance of tailoring product management approaches to the unique circumstances and goals of each organization rather than relying solely on pre-established frameworks.

Deliver value with your team

While frameworks offer structure and guidance, it's the people you work with who truly drive success. Here's what I've learned:

• Team Trumps Framework - No matter how well-crafted a framework may be, a strong, cohesive team can overcome almost any challenge. A team that communicates effectively shares context, and collaborates cohesively can often find more innovative and adaptable solutions than rigidly following a prescribed framework. However, immature or junior teams benefit the most from frameworks but tend to stick to them and create bureaucracy.

• The Power of Context Sharing - In the world of product management, sharing context with your team is paramount. It ensures that everyone understands the bigger picture and can make informed decisions. Without context sharing, even the most robust frameworks can lead to confusion and misalignment.

• Delivery Matters Most - When it comes down to it, what truly matters is delivery. Prioritization, strategy, and discovery are essential, but they are all in service of one goal: delivering value. If you can consistently deliver, things tend to improve, and your team gains confidence in your leadership. Then, you can measure your impact and iterate. But if it takes too much time to deliver, frameworks are useless.

• When things get messy, someone has to lead - in critical situation, a leader with authority may have to step up and drive the process, instead of using a framework. You can’t move an organization just because you have followed a framework properly.

• Embrace Speed, Especially Early On - In the early stages of development, speed is a competitive advantage. Rapid delivery allows you to adapt quickly to changing circumstances and gather user feedback promptly. Thus, choose light frameworks that also embrace uncertainty, like “now-next-later”.

• Strategic Prioritization Over Granular Data - Prioritize tasks strategically rather than getting bogged down in gathering excessive granular data. Overly detailed prioritization may indicate a tendency to play it safe rather than embracing calculated risks.

• Follow the Vision and Iterate - A well-defined vision is the compass that guides your product. Using frameworks without a vision will drive the teams into feature factories.

Remember, you are in this to deliver value and make a meaningful impact. Embrace the power of teamwork, keep your eyes on the vision, and continuously learn and adapt. By delivering value together with your team, you not only achieve success but also foster a collaborative and dynamic work environment.

Build your toolkit, work with people

While studying, experimenting with, and understanding frameworks proves valuable in the realm of product management, the true essence lies in developing a personalized understanding of their application. Knowing when and how to leverage each framework is crucial. However, the ultimate key to successfully managing teams and driving results is grounded in the nuanced aspects of human interaction, team dynamics, and effective communication.

Note: This post is part of the Pragmatic Product Manager series.

The Value Chain

One of the most invaluable tools in my product management arsenal is Michael Porter's Value Chain analysis. This method aids in dissecting your product's components into primary activities that generate value, elucidating their interconnections, and identifying supporting activities.

I apply the Value Chain analysis to discern how our product aligns with our customers' value chains. This examination aids in determining the following:

• Is my product addressing a primary or supporting activity? If it doesn't align with a primary activity that creates value and I cannot substantiate the value it adds, it may indicate a cost-cutting operation. Consequently, a tailored pricing strategy is necessary, but it may also encounter substantial resistance to change.

• Does my product encompass an entire primary activity from end to end, or does it only address a segment of the value chain? In the latter scenario, are there potential threats from competing products or opportunities for expansion? If I perceive that we offer significant added value, it triggers consideration of potential integrations.

• Additionally, I contemplate the workflows during my analysis. After multiple iterations and industry scrutiny, I've often come to the realization that there isn't a single monolithic value chain. Instead, there are often multiple chains, which can be categorized as (a) parallel or alternative ones based on customer types or (b) a network of value chains operating across different departments or user groups. In this interconnected web, the output of one chain serves as the input for the next.

Through this comprehensive analysis, several advantages emerge:

1. SWOT Analysis for Value Chain Components: We can conduct a SWOT analysis for each segment of the value chain. This strategic assessment illuminates opportunities for end-to-end expansion, enabling us to take greater control over the user experience and fortify our lock-in strategies. Simultaneously, it helps us identify potential threats posed by competitors encroaching on our core business.

2. User Role and Context Definition: This approach allows us to define user roles and their contextual frameworks more precisely. By crafting a narrative from the outset, even when the immediate need isn't fully addressed, we gain insights into how users engage with our product. This perspective guides our thinking towards identifying the ideal set of integrations to prioritize.

3. Clearer User Job Definitions: With this analysis, we can articulate user jobs at a granular level, breaking them down step by step. This avoids the pitfalls of overly high-level analysis and steers our focus toward providing solutions that address our customers' real problems, rather than merely adding superficial or flashy features. This is where our competitive analysis finds its foundation, as we delve into how our customers currently solve their problems – a reality that often involves something as humble as an Excel file, particularly in the realm of B2B offerings.

Naturally, the depth of this analysis hinges on precisely identifying primary and supporting activities and elucidating the intricate flows and relationships, particularly within diverse user segments. However, what makes this approach particularly adaptable and powerful is its flexibility.

You can access my generic template as a starting point, but the beauty of the Value Chain framework is that it's not one-size-fits-all. You have the latitude to define custom dimensions and parameters at each step of the value chain, aligning them with the unique characteristics of your business and product.

JTBD for different User Types

One common challenge that some encounter with the concept of Jobs to be Done (JTBD) is the perceived difficulty of putting it into practical use. JTBD is more than a methodology; it's a transformative way of thinking that can influence how you build your products, select features, and target your audience. However, it's not the sole approach, and its suitability, especially for marketing, can vary based on market maturity and competitor positioning.

After conducting a comprehensive Value Chain analysis, you'll have already begun to identify tasks that occur within your domain of interest. It's important to recognize that not every user type may be involved in every step of the process. Thus, it's time to delve deeper into each user's unique experiences—whether directly through your product or within the broader ecosystem of solutions.

One effective approach is to construct distinct value chains for different user types (or personas if you prefer). You can begin to add context to comprehend their behaviors better. In the example below, I've outlined four contextual dimensions:

• Existing Pains: What challenges or frustrations are users currently facing within their tasks?

• Expected Gains: What outcomes or benefits do they anticipate from using your product or service?

• Social Proof and Beliefs: What external influences, such as social validation or personal beliefs, might affect their decision-making?

• Obstacles: What barriers or impediments might hinder their progress?

These contextual dimensions serve as a starting point. Feel free to adapt and expand upon them based on what aligns with your team's objectives and the data available. Personally, I opt not to create highly detailed user personas during this stage of analysis. Instead, I categorize users into broad types based on key characteristics, such as technical proficiency or business intensity. Subsequently, with input from strategy, qualitative research, and data, I refine these generic user types to construct indicative customer profiles and then tell a complete story.

Practice and Iterate: Your Path to JTBD Utilization

This is the path I've forged for leveraging JTBD, and it's a journey you can tailor to suit your specific product area and its maturity. My hope is that by sharing these insights, I've assisted some of you in more effectively uncovering the jobs within your domain, all while harnessing one of my personal favorites, Porter's Value Chain analysis.

I eagerly await your feedback and the exchange of ideas on how you apply Jobs to be Done in your product analysis and mapping. Together, we can continue to refine and evolve this invaluable approach to product management.

So, why do more and more individuals aspire to become Product Managers? What are the gratifying aspects of this role that outweigh the inherent challenges we've previously discussed?

Discovering the Bright Moments of Being a Product Manager

The joy I get every time I work with a nice team and a company can be summarized in the following areas:

• You meet interesting people: One of the most enriching facets of being a Product Manager is the opportunity to interact with an array of intriguing professionals. Engaging with designers and engineers opens doors to a world of brilliance. Their intellect, creativity, and passion for their craft can make collaborating with them an intellectually stimulating endeavor.

• You develop leadership traits: The role of a Product Manager provides a fertile ground for nurturing leadership skills. It's a chance to assume a leadership role, influence team members toward achieving positive outcomes, and bask in the pride of the team's accomplishments. Particularly if you've encountered ineffective management early in your career, the experience of empowering your team can be deeply gratifying. Contrary to the notion that leaders are born, the path to leadership as a Product Manager involves mastering effective communication amidst information overload, quantifying impact, disseminating insights within the team, and striking the right balance between guidance and autonomy.

• You learn new things about business and management: The dynamic role of a Product Manager extends its reach across various dimensions of a business. As you interface with different functions and navigate through the unique structures of each organization, every company becomes an opportunity for learning. With each new company, it's akin to embarking on a mini-MBA journey.

• You develop a holistic, service mindset: As architects of experiences, you craft not just interfaces but bonds, not just features but narratives (or we should do so). When you start working like this, you will start challenging many aspects of the services and the products you interact with in your life, making more informed decisions, or seeking holistic experiences that ease your life.

• You never get bored: I have never heard a PdM complaining about doing nothing. I have heard some being thankful that there is stability and less intensive periods, but you will notice that if this is prolonged, a Product Manager will soon seek a new challenge, within or outside the company.

• You are an entrepreneur with a safety net: Product Managers operate as a unique breed of low-risk entrepreneurs. The role provides the latitude to explore markets, anticipate industry trends, and venture into uncharted territories—minus the extreme personal risks typically associated with entrepreneurship. If you've been an entrepreneur with past endeavors that didn't pan out as expected, the role of a Product Manager offers a fresh avenue to construct and innovate, all within a structured and safer environment.

• You can be a visioner: The principle of a product is that it needs to deliver something that scales, increasing the revenue faster than the cost, finding a market that scales, and going fast towards there. You can’t do that if you don’t have a long vision, even if you are successful early on someone else with a bolder vision and a plan will find the resources to outpace you. If you like to see the big picture when others seek to complete a task.

The dark side of positiveness

As the veil of positivity unveils, it becomes evident that even the brightest moments harbor their shadows—the gray areas that add depth to the canvas of being a Product Manager.

• The Duality of Compensation: Many people who want to climb into the corporate ladder, see Product Management, which doesn’t need studies, as a good alternative to build a stronger career. By managing substantial budgets, Product Managers frequently enjoy well-deserved financial rewards correlated with their product performance. Yet, this prosperity breeds competition, opening the door to collaboration with individuals who prioritize personal gain with short-term wins (agency problem) over shared objectives. As you ascend to a Product Leadership position, the challenge evolves to discern these motives, ensuring a filter against toxicity seeping into the team's culture.

• The Weight of Influence: The fact that you affect decisions, creates a sense of power for many people. You may notice people crashing if they get too much power or many responsibilities, without previous experience. You may meet people that have a big ego and want to command. Or you may meet people that follow the numbers because they are afraid of using their product sense and defend their vision and decisions. Power comes with responsibility, and PdMs are well affected by it.

• The instability of the role: Yes, it’s fascinating to learn constantly, to try to adapt to the market, to expand, to study competition and trends, and to think about how the future can be. But there is mental tiredness as well. Many PdMs tend to have burnout in their career, and only if they get more senior they can try to balance and control it. I believe the best approach is getting sabbaticals every 4-5 years, but it needs good planning and financial management.

Stay positive

Hence, these are the reasons that make me keep dealing with Product Management and Leadership, even in moments of doubt or my personal mental lows. No one is perfect, no one is constantly effective, and no PdM is the single reason for the success or failure of a Product. We have to enjoy and understand the craft we are within. I hope I gave a positive aspect of our craft.

I devoted significant time and effort to these practices, often finding myself frustrated when others failed to grasp the value of my work. It seemed that some individuals believed they held the best ideas and were determined to push them forward, oblivious to the insights I had gathered. Looking back, I recognize that not every endeavor I pursued was fruitful, but overall, my approach inspired and motivated teams, yielding positive outcomes despite the challenges posed by difficult stakeholders. This track record eventually led me to a leadership position where I aimed to build a team that shared the same principles—a new challenge in itself.

However, as I advanced in my career, I observed a recurring pattern: many people around me acted on intuition or authority, making hasty decisions without adequately sharing the context behind them. When their choices turned out favorably, they were hailed as wise; yet, when outcomes proved them wrong, they swiftly rationalized their decisions and shifted blame elsewhere. It would be understandable if these individuals were seasoned experts, but even those lacking experience seemed to exhibit similar behavior. While I acknowledge that luck plays a role in success, this cannot be a carte blanche justification. Curiously, these individuals often dismissed my work as "academic," "theoretical," or accused it of "over-analysis" , and most impressively, they were keen on finding the weaknesses of my work.

Eventually, I came to the realization that the lack of appreciation for my work may stem from a broader issue—an unfavorable organizational culture and uninspiring leadership. Changing such deeply ingrained elements within a large organization proved to be an insurmountable task. However, I also recognized that there were still actions I could take, regardless of the prevailing culture or leadership quality. Whether I chose to continue working within a culture I had not anticipated upon joining was a decision I could make, armed with the knowledge that there were ways to make an impact regardless of the circumstances.

So, what can you do when you land on tough cultures or situations?

1. Be an owner

Being an owner is a fundamental aspect of a healthy organizational culture. In a good culture, individuals willingly take on responsibilities, proactively offer solutions instead of dwelling on problems, and demonstrate the capacity to make decisions while respecting managerial authority. Conversely, in a poor culture, you may encounter individuals who shy away from accountability, only highlight issues without proposing remedies, and complain about managers who fail to grant them decision-making autonomy.

To navigate these dynamics, it is crucial to invest time in comprehending the priorities and goals established by the organization's leadership. Engage in discussions to gain clarity, refine objectives, and align perspectives. Rather than attempting to espouse grandiose notions of strategy and vision, focus on understanding the concrete goals, where the company aspires to be in the next 3-5 years, and how success is measured. Rather than imposing your own vision, collaborate with others to shape and build upon existing ideas and pathways.

Subsequently, develop a plan to address these goals, taking into account the input gathered during the process. Refine the objectives, prioritize your actions, seek feedback from stakeholders, and propose improvements or alternative approaches. Shreya's LNO framework or Eisenhower's matrix can serve as useful tools to guide your energy allocation. Along the way, you may find like-minded individuals who are willing to join you and contribute their efforts towards this shared direction. By fostering a sense of ownership among colleagues, you can collectively work towards achieving the desired outcomes.

2. Timing matters

Timing plays a crucial role when it comes to implementing changes within an organization. Often, the most opportune moments for change arise during times of crisis. Whether it's losing a valuable client, experiencing financial constraints, or facing talent shortages, these situations can serve as catalysts for improvement. It is remarkable that many individuals only feel compelled to seek improvements under the pressure of imminent deadlines and challenging circumstances. However, this urgency also makes implementing change more challenging.

In the absence of an impending crisis, you may find it necessary to create a sense of urgency or find alternative approaches. One option is to "make up an enemy" or identify potential threats that could negatively impact the organization. This simulated adversity can serve as a motivating force to drive change. Alternatively, exercising patience becomes essential. Work alongside others within the organization, collaborating to shape a shared vision and approach. Observe the impact of your efforts, appreciate the results, and effectively communicate them to other teams. Over time, the change you initiate can spread organically, like a virus.

Whether you choose to address change from a top-down perspective during a crisis or patiently and quietly at the team level bottom-up, it is essential to recognize your own limitations and boundaries. Understand what actions you can take within the scope of your role and what is permitted by the organization. By navigating within these parameters, you gain valuable insights into what is achievable and how you can contribute to the transformation of the organization.

3. Don’t ask for a job description

When it comes to the role of a Product Manager (PdM), there is no one-size-fits-all definition. As you may recall from my past post on the subject, the responsibilities of a PdM can vary depending on factors such as the organization, the product's stage, and the overall environment. For instance, if you have a CEO who possesses a strong Product Sense and a clear vision, your role won't involve challenging that vision but rather creating your domain within which you can define your own solutions and roadmap while aligning with the overarching product goals. Conversely, if you are in a sales-driven company, you may need to educate others on how a Product-Led Growth (PLG) strategy can benefit the organization or focus on creating a platform to fulfill specific requests.

Instead of fixating on a job description, it's crucial to keep in mind that, regardless of the organizational structure or the specifics of your role, you should collaborate with other departments such as business, marketing, and customer support/excellence on a regular basis. Don't wait for someone to tell you to engage with different stakeholders, have frequent sync-ups, or facilitate workshops. However, the trickiest part of this process is effectively communicating your message and adapting your expectations based on your audience. You may encounter difficulties and find yourself needing to explain or reiterate certain points, but effective communication is a fundamental aspect of your job.

As the Product Manager, you serve as the glue that ensures customer value remains intact throughout the entire customer experience journey. If other departments are open and cooperative, consider yourself fortunate, as they have likely worked with Product professionals before and understand what is expected. However, it's essential not to take over their responsibilities on a daily basis. Instead, establish a proper interface with them, set expectations and goals, and allow them to manage their own processes. Conduct regular follow-ups, and if they fail to deliver, you may need to assume certain parts of the process and communicate the resulting overhead to the organization and your manager. This could lead to discussions about the need for defining a new role or hiring additional personnel.

If you encounter protective behavior or internal politics within other departments, engage in conversations with them to emphasize that your aim is to prioritize the best interests of the customers. If you encounter resistance or walls, it may be necessary to involve higher-level management, such as Directors, VPs, or the CEO, to drive change within your organization. The best way to foster collaboration with other departments is by working together on the Go-To-Market plan, once you have agreed upon a clear and shared deliverable using techniques like the Press Release document (PR/FAQ).

4. Get out of your comfort zone

It's natural to rely on the learnings, playbooks, and frameworks that have proven effective for you throughout your career, regardless of the organization. Staying within the same industry can also provide a sense of ease and empowerment, as you don't have to continually learn about new markets, competitors, trends, and business dynamics. Moreover, these criteria often form the basis for initial screening during the hiring process, as companies seek candidates who can hit the ground running, understanding the industry's nuances. This preference for safe bets in hiring is particularly prevalent due to the shorter tenures people tend to have with organizations. If you have a family and prioritize stability and free time, smoother career transitions can be highly valuable.

I wholeheartedly understand and appreciate these factors, especially as I grow older. However, I also recognize that the most crucial aspects of one's career lie in the principles and practices that work well with teams, the evolution of communication skills, and the realization that luck, timing, and uncontrollable factors also play significant roles in personal and product success. As one gains seniority, managing uncertainty becomes a significant achievement.

For these reasons, I make a conscious effort to step out of my comfort zone from time to time. I made the decision to pause academia early in favor of venturing into social media startups. I juggled two projects while completing my Ph.D. in software engineering. I attempted to secure pre-seed funding for a healthcare startup, even contemplating leaving my home country for an HR startup that eventually closed its UK offices. I chose to forego lucrative job offers in London's banking sector to go all-in for a music startup, which turned out to be a successful bet. However, after four years, I decided to take a sabbatical to explore new technologies before joining a highly promising tech startup.

During these transitions, I encountered skepticism during the screening process and faced steeper learning curves. However, I also gained valuable cross-industry insights, developed diverse playbooks, and stayed updated on emerging technologies and operational systems. This allowed me to differentiate myself from those who solely focused on one industry and defended the status quo. I recognized that nothing remains static, and competition can arise from various dimensions, necessitating innovation on multiple levels.

Therefore, I firmly believe that as a Product Manager, you bring value to your organization by embracing diversity and venturing beyond the confines of a single industry. Embracing new industries offers the excitement of exploring different business models, encountering unmet markets, and solving problems you couldn't have imagined otherwise. By fostering a diverse perspective, you contribute to the innovative potential of your organization and continuously expand your own knowledge and skill set.

Try, do your best, but set a red line

If you've been following my posts, you'll notice that the topic of leaving an organization at the right time and in a healthy manner is a recurring theme. Your physical and mental health, as well as your work-life balance, are among the most important aspects of your life. As you gain experience and grow older, you come to appreciate these factors even more. In the early stages of your career, you may tolerate certain behaviors, work overtime, and clean up after others to help the organization succeed. This mindset may even help you climb the career ladder initially. However, you will soon realize that simply working hard is not the path to happiness, good health, or increased appreciation.

It is crucial to make a conscious decision about what matters most to you. Will you prioritize working for a company or holding a job position that looks impressive on your CV, or will you focus on enjoying your work, personal growth, and living a fulfilling life? Especially in today's world, where remote work is increasingly possible even post-Covid, you have more flexibility to find a balance between your work and personal life. You can explore opportunities in countries with a lower cost of living, enabling you to maintain financial stability while enjoying a better quality of life.

Seek out organizations that empower you, bring you happiness, and offer opportunities to pursue meaningful work. It's important to find a workplace that aligns with your values and provides a conducive environment for personal and professional growth. By prioritizing your well-being and seeking out fulfilling opportunities, you can create a harmonious balance between work and life, leading to a more satisfying and rewarding journey. Remember, it's essential to establish boundaries and set a "red line" when it comes to compromising your health and overall happiness for the sake of a job or organization.

PS: This post is part of the “pragmatic product manager” series.

The main reason people prefer building products from running projects or offerings services is that a product can scale; selling and using a product is a repetitive process, standardized, and if there is a market fit, economies of scale will allow the organization to grow faster.

This fast growth is why Silicon Valley (and relatively thinking VCs outside SV) is thinking that way; VCs know that they bet on high-risk companies, but they expect high returns. Thus, they invest by definition in companies that build products. Thus, regardless of the strategy for validating the market, with processes that don’t scale initially, the end goal of each SV-backed company is to build a product and capture a market, if not create one.

If you are outside the Silicon Valley ecosystem and the broader VC network, the terms and rules change; you need to find a way to fund your company. If you are on trending topics with founders with a great profile, a nice prototype, and promising numbers, you may get access to early funds and get connected with overseas investments. So, how should Product Managers position outside a world that is not Silicon Valley, or doesn’t think like Silicon Valley?

There is an interesting life beyond SV

Should we expect that Product Managers outside Silicon Valley are doomed to apply only to a limited pool of companies that think Product-first? The answer is that part of the job of Product Managers (and especially Product Leaders) is to help organizations make this transition to a product mindset and strategy, which will allow a company to be more competitive and grow faster.

If everyone in the organization has an honest need to become product-first (product-driven, marketing-driven, sales-driven) and you win leadership’s trust, then you need to be a “pragmatic product manager” and find your own way to help the organization on this trip.

In the process, you may get tired of the lack of experience and any inertia, make steps back to educate and prepare the organization, before you try to fight the status quo; in the end, if you realize your efforts don’t have any effect, you may leave the organization. But before we discuss a no-happy ending, here is a list of tips to help you survive in a non-product-thinking organization that says that wants to change.

1. Be a product ambassador

The first thing to do is to educate people within the organization. This is part of your job, even if it is not in the job description. Here is your checklist for onboarding a non-product-driven company:

• You should explain that the product is the business model; It’s the whole configuration and the user experience, it is not only the working software.

• You should explain that the Product Manager is the driver and facilitator, not a CEO or other function challenger.

• You should explain that delivery is not your job, it’s the engineers’ and designers’ role, but it is critical for everyone’s existence thus you are closely monitoring and driving it. Your performance should not be evaluated based on features, but based on the value created, so you have to start measuring and defining what success looks like. Otherwise, the engineering team will be a cost center.

• You should find the proper balance among your product sense, Founders’ vision, data, and qualitative information. You should measure things and work to define a North Star, but prefer to tell stories, at least until you have a market fit for your product; then you can be data-driven in your decision-making. Don’t overpromise that numbers will define the solution. Growth comes later.

• You should talk more about Product Vision and Strategy. This is a skill you have to develop. How will your product be in 1 or 2 years? How does it make sense to automate more parts of the process? If you don’t work on these topics, no one will. How can the product help the organization meet its expectations and even take it one step closer?

2. Connect with other product people

If you are in a situation where your company doesn’t get what Product Managers are about, you have to realize that you are not alone. The most important thing is to find people that are open and realistic, to share their experiences, and help you find solutions to your problems. You should look for or create local communities and meetups, but if you feel isolated in your country, follow people on Twitter, Substack, and LinkedIn, like or . These people may be SV related, but many of them are open to discussions and you may find other people in the relevant communities to exchange opinions.

Personally, the way I worked through tough times was the following:

1. Try to find a name for your problem. Semantics is important. Is it a strategic problem? Is this a process? People?

2. Search online for blogs, books, and videos talking about these issues. Follow people talking about relevant topics.

3. If you can’t find things answering in much detail, shout out on social media for references. Reforge has lately had an amazing library of topics with many topics to choose from.

If you do the steps above, you will realize that you are not alone. But you should search for solutions actively, and read a lot.

3. Avoid arrogance

In the process, don’t be edgy or communicate that building products is the only way to success. You have to realize that products require investment, and have a high risk of failure as well. Yes, we all love to harvest the goods of a product with a market fit. So, even if you have worked on successful products, and you did things with impact, don’t take it for granted that people should think and act like you, or that you get a free pass to work as you want. You need to align expectations quite frequently.

I personally give two examples that help my audience understand how I can contribute to the company, by bringing products in the core of the company’s offering:

1. Look at your P&Ls. If they grow linearly, you can’t scale as fast as other product companies, and you can’t have such evaluations. You can choose not to become such a company, it’s ok. But if you want to have exponential growth while keeping your costs low, you have to productize parts of your offerings. Usually, people want to build the next unicorn and capture the whole market, so it is a rhetorical question.

2. Ideally, if there is a validated market and the required budget, a product team would automate the whole user experience. Any human interactions and interfaces would be to provide a premium service for segments that need it. The only reason not to build a product is if there is no big market or you expect the market to change behavior soon. Our response to this uncertainty is to ship things in smaller experiments so that we can validate the market response and adapt to any change.

You should avoid being arrogant, but you should also avoid the Halo effect while talking with other successful PdMs; Listen critically to advice from people who only run processes at well-established tech companies, they will get you confused. While I was looking for advice, I got an answer from Product people in big Techs like “I do run my OKRs, and sync on a weekly basis with my team, then measure everything to adjust”. This is not the actual world of Product Management, this is a part of Product Management for people working in Big Tech companies who don’t have primitive problems like finding a market fit before funding ends. Thus, if you try to pass any advice as-is in practice, it is very possible to fail.

This is not a race with one winner. Try to learn from other PdMs from their experiences and their failures, not from their CVs.

I don’t say that PdMs with experiences from big Tech are not worth it; I have met some great guys and some people have amazing organizational knowledge to share, especially people from Amazon (personal preference). What I want to underline here is that Product Management is affected also by luck and the environment they operate in sometimes, beyond the effort they make or the skills the PdMs have.

Remember: Every transformation is hard

Transformations usually fail, but in the end, you will be wiser than before; you should do your retrospective for the failures you had; Why did they happen? Could you do something differently? Did you lack skills, were you in a rush, did you communicate things in the wrong way, or it was the organization’s resistance to change? You know, sometimes people in high-level management prefer to pay external consultants to do the job of transformation that should be done organically, to secure their position and sound smart and sophisticated.

As heads-up, here is a list of the most common problems you will face in the process of transforming an organization:

• Lack of understanding about what a Strategy is, and difficulty to prioritize.

• Politics from people who fear becoming obsolete, and undermine changes that will put their job at risk.

• Product may challenge existing revenue streams from clients (kill the fat cow - innovator’s dilemma).

• The agency problem; managers prefer to get their bonuses and salaries by optimizing in a certain market rather than taking the risk to invest in new markets, new business models, or new offerings.

• Lack of market fit, that doesn’t allow the product to take off. Whatever you do or try, you have no impact and you can’t bring any change because there are not many clients (in size and number) to buy what you are offering.

Thus, embrace any frustration, do your job with transparency and goodwill, design for small wins before you change the whole organization, and try to show what value you can create early on. Be a pragmatic Product Manager.

PS: This post is part of the “pragmatic product manager” series.

PS2: Yes, there are many other hubs beyond SV and many other US areas that are very strong. But gravity and ties are strong around SV. You can replace SV with any other strong entrepreneurial ecosystem.

In this blog post, I will reflect on my own experiences and share what I have learned about what I call a “Pragmatic Product Manager”, to explore the importance of realism in product management and offer insights that may help other Product Managers improve.

A. You work for an Organization

1. Be an Owner - Take the time to understand the priorities and goals of the organization's leadership. If you don’t like something, try to change it. Don’t complain or wait for someone else to do it. However, it's essential not to take on too many responsibilities and burn yourself out; if you can move things with others it is great.

2. Timing matters - If you find yourself frustrated with the lack of progress or change within the organization, try to be patient and wait for the right timing and opportunities. If you feel like you're making too many compromises and not making any headway, it might be time to consider moving on.

3. Don’t ask for a job description - Expect to do the work of other departments from time to time, like business, marketing, and customer support/excellence. You are the glue, and you need to be sure that customer value doesn’t break through a long customer experience flow. If the other departments are open and polite, you are lucky, they have done it before. But don’t do their job on a daily basis; Build a proper interface and leave. If they are protective, they play politics, you should discuss it with them and try to explain that you want the best for the customers. If you find walls and bad behaviors, it may be up to the Directors/VPs/CEO to change things in your organization.

4. Get out of your comfort zone - No one is perfect. As PdM, you give value by being diverse. Possibly, from time to time you may have to leave the PdM role and do something else. Don’t stick to an industry or a series of well-known companies. You miss the fun of mixing business models and ideas, learning unmet markets and problems you couldn’t imagine. Or you may stay behind in the latest developments.

Read more here.

B. Silicon Valley Fallacy

1. Be a product ambassador - it's essential to recognize that not every organization can operate like those in Silicon Valley. Don't wait for your organization to follow an SV playbook; they may not have the resources or know-how to do so. Many companies that have achieved a market fit and use Product Led Growth tout the benefits of being product-driven. However, if your organization doesn't have these characteristics, it can be challenging to convince the business-driven leadership to give more power to the product teams. Help them understand what Product thinking is and why it is valuable. Be your own ambassador; it is part of your job.

2. Connect with other product people - if you find yourself struggling to influence change within your organization, you should know that you're not alone. Talk to others in similar situations, share your struggles, and seek out insights from those who have successfully transformed their organizations. Remember that change takes time, effort, and a willingness to take risks from management.

3. Don’t be arrogant - If your product succeeds and there is a market fit, maybe you were lucky. If you ride a high-growing market, you will enjoy the glory of the success of the early builders. If you have a large budget to try things, you work for a prosperous and lucky organization. If you haven’t eaten sh*t trying to do things ground up on your own, or with limited resources and much politics, be proud of what you have done but don’t be arrogant. This is not a race with one winner. Try to learn from other PdMs from their experiences.

Read more here.

C. Learn frameworks, then strip them down

1. Build your toolkit - Learn about frameworks. It’s someone’s mnemonic or standardized rules. Before implementing a new framework in your organization or sharing it with your boss, try it out internally first. Understand how and when to use it effectively. If a framework proves to be effective, you can share the results but don't demand widespread adoption. Remember that other Product Managers or teams may not have the same context or experience and may struggle to implement the framework. Ultimately, you should use the tools and parts of the framework that work for you and build your own Product Management Toolkit.

2. Deliver value together with your teams - Don’t forget, you are there to deliver value. Discovery is important and prioritization is necessary, but delivery is all that matters; It's your skin in the game. Learn how to prioritize things that create value. Speed matters, especially in the early stages. Keep your process lightweight and focus on fast delivery. If your prioritization needs granular data to be effective, it feels more like you want to cover your *ss in case of failure. This is why your teams should be Agile, to minimize the risk of failure, not to follow their ceremonies. Ship, measure, understand, think, and repeat, in iteration.

Read more here.

D. Avoid team traps

1. Be a team player - As a Product Manager, you're only as strong as your team. Be transparent, honest, and fair with them. Instead of lying, let them know when you need time to back up your decisions with evidence. You're not superhuman, and you need a strong team to succeed. Motivate your team by making them feel that their contributions are impactful.

2. Be transparent - Don't cut your team off from clients or insights. Transparency is key to maintaining their trust and motivation. Remember that you don't have to be the smartest person in the room. Your team needs clarity, confidence, thoughtful decisions, and passion. Give credit where credit is due.

3. Don’t be a people pleaser - You shouldn’t be a glorified secretary for Tech or Business. You are not there to protect or pumper engineers, you are not a messenger of business either. Avoid bullsh*ting. Avoid making excuses or changing your opinion frequently to justify mistakes. Be upfront and honest with your team. Avoid rationalization. If you disagree with upper-level management, express your views, but don't let it consume your team's focus on the current reality.

4. Learn to Lead - Try to find time to think about the future. Probably no one does, and you will soon be obsolete.

E. Data is good. Interviews are better.

1. Understand the data - Most Product Managers claim they are data-driven; It’s like Teenage Sex, everyone has done it. Your metrics make sense to you, the organization, and the product development phase. Keep a log/journal of your releases. Try to see if something affected the product. Be aware if an external or marketing event affected your numbers. As Amazon does, separate input from output metrics and clarify what you expect. Many PdMs say they track revenue metrics, how many of them affect them and how do they know it?

2. Decide with context - Teams based only on data are as bad as teams that are based on HiPPO. Your users are not represented by numbers, even if they fit into clusters. Try to create some magic, impress your customers, and create the unexpected. You can optimize it later with data. Be smart, and talk with your customers, engineers, and operations. Collect opinions and try to find the underlying problems. When talking about problems and your product, you may have an epiphany.

F. Communicate effectively

1. Write, write, write - Writing things down increases clarity. The material you write may reach more people more easily than your word. By exposing yourself to a document, you gain more ownership; you are credible and accountable for what you ask for.

2. Get Visual in Iterations - People react to visual information faster and better. Why don’t you try to visualize your ideas? Everyone has an opinion until they get something tangible and say that this is what they were thinking. In the process, if your idea sucks, you will drop it before you present it. Iterate from documents to visualizations and back to documents. You will find out how much clarity you get through this process.

3. Don’t share drafts - People with strong opinions or bad intentions may use them against you, thus clarifying when something is a draft may be useful; but typically you should better hide it from public sight. When communicating your final work, however, try to narrow it down to the essentials and link it with any additional content for elaboration.

4. Meetings are a threat - You should consider meetings as a potential time waste, most of the time. Have this in mind and try to optimize this time for everyone. It’s preferable to go with your team or colleagues for coffee/drinks instead of attending pointless meetings. You may have to add and remove regular meetings until you find the frequency that makes sense. Make it clear and don’t be afraid to make changes that matter. Attending meetings and answering emails is not a job, it’s your tools. Use the LNO framework to avoid it.

PS: Thanks for the feedback from on this topic. Sharing common experiences helped me shape this article.

PS2: As experiences and details matter, I am thinking of writing one post for each topic. Feel free to leave your comment on the topics you may be interested in reading about first.

We have all seen the popular Venn diagram about UX, Tech, and Business, which has multiple variations with more and more cycles. But what is a Product Manager? Is she the CEO of the product (cliché)? A facilitator? A decision maker? A leader? The representative of the customer within the organization? The glue that connects objectives with execution? The person that leads the discovery process? The innovator that comes up with new ideas? The project manager with marketing and tech understanding? Is everything above, in different phases or companies?

To better understand the job of the Product Manager, we need to disconnect the product manager role from the job. People within a company may act under the role of product managers occasionally, while the job of a Product Manager is to be in the position to manage a product (or part of it) within a certain phase of its lifecycle.

Note: Below, when I refer to the role it will be lowercase, when I refer to the Job it will be described as Product Manager.

The role of a product manager

Definition - A product manager is a person who is responsible for the product lifecycle of a product (or part of it) within a company, aka the creation, development, maintenance and reconsideration of it. It may be a dedicated position, but various people occasionally may act as product managers, especially in the early stages of a product where full control is required.

The product manager is the master of the Product Development process. From conception to delivery, from evaluation to iteration. To create and maintain value for customers and organizations through a business model. In other words, the one defining and explaining what and why should be built and shipped to the customers; then increase learning and get back to development.

This role changes over time as well. Initially, you need someone who is effective on Zero to One, then someone good with Growth, then people who can Optimize parts of the offering, and finally someone that may work to Transform the product and work on new ones. Considering that at each stage only Product Managers can make it, it is a mistake; at certain stages, different people with different skills may be more appropriate to manage a product and the product teams.

This is where entrepreneurs and managers get confused. When they start a company or new business initiatives, they may be the product managers. Lucky, scrappy, or ingenious, they did everything or were the force that created an innovative product; including support, operations, hiring, accounting, and raising funds. But soon they realize (or someone tells them) that they can't do everything because building things requires time and effort, and you can’t have a context switch. So, it soon became profound that specialized people in various areas should take over the management of the development process.

The job of a Product Manager

Definition - Product Manager as a job is the dedicated position of acting in the role of a product manager, and it a specialized person able to apply the function of product management on different environments to drive the product development lifecycle.

Eventually, the role of the product manager evolved into a specialized person who can understand data, apply frameworks, tools, best practices, and experiences in order to increase the expected value from a Product Development process - both for customers and the company - and reduce the risk of failure through Discovery. Today, you may find different types of Product Managers, even if this is not profound to the job descriptions or the hiring process.

Definition - Product Management is a function that takes as input the resources, skills, and context of a business in order to generate value for the customers through the delivery of the product experience, and as a result for the shareholders.

This job of managing the product development lifecycle includes many different aspects, as described in his very interesting article"What is product management? What we describe as managing the lifecycle gets more detailed by working with the team on the output (shape) and making what is necessary to go in production and reach the market (ship). In that process, you may have to collaborate with multiple people within the company, thus you have to sync with people.

To understand what a Product Manager has to deal with, we should unfold the context in which she operates; Below you can see what should be taken into consideration to work on product development and all the departments and people that they have not only to sync with but also to engage and collaborate with. Everything starts with the vision of where we want to go and the strategy to reach this point. This message is expressed through positioning, which may not be clear by the time we launch a product and may come later. This direction forms a business model, which is what the client buys as an experience. So far, a Product Manager should interact or take input from executives, co-founders, and business people that are running a company or a business unit.

Then, (ideally) with a Press Release, the team starts the implementation and alignment of what and how we build with the Go To Market strategy. At this stage, a PM should interact with Marketing, Business Analysts, Finance, Operations, Sales, and possibly with Legal to align the entire Product Development roadmap. If we take into consideration that in an agile world with a lean approach and releases, there are pivots, delays, and iterations, you can realize the overload of information a Product Manager has to manage. The bigger the organization, the bigger the overhead, which makes things almost impossible to complete. For that reason, flat structures and Single Thread Leadership for the initiative are highly recommended, to increase the chances of success. This is why we end up with so many complex diagrams, describing what makes a competent Product Manager.

Why and when you need Product Managers

In a company that sells a product - or builds a product to offer a service that needs technology - someone has to be responsible for what is built and why. Someone has to sync external forces with internal capabilities and manage the process on a continuous basis. If you don’t have any, you need a Product Manager… yesterday.

Behind every great product there is someone—usually someone behind the scenes, working tirelessly—who led the product team to combine technology and design to solve real customer problems in a way that met the needs of the business.” - INSPIRED, Marty Cagan

If you are the co-founder, you will notice that at some point your time, focus, or energy on the product starts to decline, or that you haven’t done it before and you don’t know how to do it. This is a signal to hire a Product Manager.

For that reason, I decided to collect in this post some of the most useful, less and more popular, explanations about what innovation is and how it works, with emphasis on Product Management and Development.

The Basics of Innovation

As Everett M. Rogers describes in his book “Diffusion of Innovations”.

An innovation is an idea, practice, or object that is perceived as new by an individual or other unit of adoption. It matters little, so far as human behavior is concerned, whether or not an idea is "objectively" new as measured by the lapse of time since its first use or discovery. The perceived newness of the idea for the individual determines his or her reaction to it. If the idea seems new to the individual, it is an innovation.

Newness in an innovation need not just involve new knowledge. Someone may have known about an innovation for some time but not yet developed a favorable or unfavorable attitude toward it, nor have adopted or rejected it. The "newness" aspect of an innovation may be expressed in terms of knowledge, persuasion, or a decision to adopt.

This is the reason that many people believe that innovation has diminished in meaning and importance lately, as many things have been labeled as innovations, while many people believe that old ideas are not innovative and they are looking for new shining ideas and technologies. Globalization has brought a bigger balance among nations, making it easier to spread ideas and products, thus it is considered that if something is an “old idea”, it is not innovative.

To better understand innovation, we have to understand the concept of “Diffusion of Innovation”. A nice example explained in the book is a campaign for boiling water in Peruvian Villages to battle infectious diseases; for people not being aware of it, this would be an innovative practice, as the definition of innovation explains. In a certain village, the concept was dropped because culturally only sick people were drinking boiled water, and only some outcasts adopted this innovation. Thus, we have to take into consideration another dimension.

Diffusion is the process by which (1) an innovation (2) is communicated through certain channels (3) over time (4) among the members of a social system.

As you may have noticed, we have introduced the idea of early adopters, and the concept of “the Chasm”; a channel of diffusion that may fail within a specific social system for a certain time period. Thus, we shouldn’t forget that timing and channel diffusion are important factors that we don’t control, and there are other factors we may control in our go-to-market strategy.

If you want to understand the dimensions of timing for new ideas and startups, you should watch the following TEDx talk.

If you are still wondering why a Product Manager should be aware of the innovation lifecycle, you should have noticed that the way your product captures a market is the way an innovation penetrates (or fails to) into a certain social system, for a certain period of time. Putting everything together, about how product life cycle and diffusion of innovation are interrelated, you can see the following diagram. I strongly believe that understanding the lifecycle of your product is important as a Product Manager, thus I found studying innovation very useful.

Business Dimensions of Innovation

If we add the dimensions of the market where a solution is introduced and technology that is used to address a market need, you can find 4 different types of innovation:

• Incremental innovation refers to a series of improvements to a company’s products or services over an extended period of time.

• Architectural innovation refers to reconfiguring components or technologies of existing products so that a company can enter a new market.

• Disruptive innovation refers to challenging an existing market by delivering more value to customers. The intention is to focus on customer needs through a combination of technology, pricing, and services.

• Radical innovation refers to creating a new market with a breakthrough solution.

With more focus on market characteristics, you can start unlocking useful focus areas of a product launch, like where to look for competition, what customer needs you should address primarily, and where your offering should outperform. If you want to drill down on how you can build your marketing strategy while you build a new endeavor, you will find the 4 Steps to the Epiphany very very useful.

A very thorough playbook explaining all the different areas of a business model where you can innovate is Ten Types of Innovation. I like playing around with the different configurations, and see what the outcome could be.

However, what is missing is the evolution of innovation through time and the dependencies that there are. For example, a disruptive technology needs the time to overcome the chasm and access the mainstream market, while you cannot build a service innovation if there is not a product innovation first, and then you should wait for the business model innovation.

The Phases of Innovation to capture bigger markets are:

• Product Innovation - Takes established offers in established markets to the next level. The focus can be on performance increase, cost reduction, usability improvement, or any other product enhancements.

• Process Innovation - Makes processes for established offers in established markets more effective or efficient.

• Disruptive Innovation - It tends to have its roots in technological discontinuities.

• Application Innovation. Takes existing technologies into new markets to serve new purposes.

• Experiential Innovation. Makes surface modifications that improve customers’ experience of established products or processes. These can take the form of delighters (“You’ve got mail!”), satisfiers (superior line management at Disneyland), or reassurers (package tracking from FedEx).

• Marketing Innovation. Improves customer-touching processes, be they marketing communications or consumer transactions.

• Business Model Innovation. Reframes an established value proposition to the customer or a company’s established role in the value chain or both.

• Structural Innovation. Capitalizes on disruptions to restructure industry relationships.

I like giving an example of Innovation evolution with Digital Music in mind; General Magic was one of the first portable devices without crossing the chasm, the Internet with piracy disrupted the market, iPod came as a Product Innovation for portable digital music, iTunes launched as a service on top of this product to sell music, iPhone with mobile Internet boosted consumption, and Spotify innovated on the business model level with its subscription model where Apple switched as well with Apple Music. And now that the market is close to a cap, the main discussion is about regulating the markets of China and India, and fixing the problems in the whole supply chain of copyright management with all its deficiencies. All these events were not always serialized, but they had a logical dependency.

Innovation & decision making

I have pointed out how difficult it is to be creative in previous posts, meaning putting into effect new ideas on existing systems or organizations. Thus, if we consider that we have configured our product properly to increase the chances of a successful product launch, taking into consideration the context of our launch, we have to convince our organization (or external institutions) to fund our initiative and build a business around it. To better understand how it works, you should understand the concept of Counter-Positioning.

Counter Positioning - A newcomer adopts a new, superior business model which the incumbent does not mimic due to anticipated damage to their existing business.

If we could measure the Net Present Value (NPV) of a new endeavor, there would still be reasons for an organization to drop or for a competitor to ignore an innovation:

• Milking: Negative Combined NPV. In that case, the organization prefers to “milk” the fat cow that generates money until the market fades out because it doesn’t make financial sense to enter the new market.

• History’s Slave: Cognitive Bias. NPV is positive. The decision maker based on history is biased and makes a subjective decision.

• Job Security: Agency Issues. The decision maker’s interests are not aligned with the organization’s, e.g. bonus mechanisms, or career growth incentives.

With all this struggle to make Innovation attractive for an internal or external investor, you can understand why it is so difficult for managers to bet on Innovations - as I stated before -, and we are waiting for outcasts to bring in new gameplay and innovations in the market.

Key takeaways

While putting all this material together, to create a meaningful scraping over innovation management and history, I tried to create a thorough but incomplete list of takeaways for PMs, at least the way I interpreted the useful learnings from studying innovation.

1. Timing - Timing is one of the most important factors for launching an innovation.

2. The Product comes first - You can’t build a strong process innovation without a strong product, if not yours a product you can build on it like a platform.

3. Dominant Design - In a premature market, you may risk building a service over a non-dominant design.

4. Innovation within a new channel - If you launch in an underserved and underdeveloped market, you may need to look to simple, existing, and low-cost ideas that you do not consider as innovative.

5. Politics and resistance to change - whether you like it or not, that’s the world. You have to manage it or leave.

6. Know that there are playbooks - You can bring innovations from other markets and businesses. Don’t think that innovation should be something completely new.

7. To Innovate, go out of a system - Sometimes you have to create an independent initiative within your organization, or drop your current role, to be in a position to Innovate. As a friend told me once, “it’s easier to ask for funding from your organization than asking for certain people to join your new initiative”.

Indeed, when I ask people I manage to think big and come up with new things for their products, usually they don’t know what to do and how to do it. No one teaches you how to be creative in the end…

I have realized how little the need for a Product Manager to be creative is discussed. Thus, in this post, I have collected some tools and processes I have been using through the years.

Creativity 101 for Product Managers

To increase your creativity as a product manager, it's important to adopt the right attitude. This means avoiding the temptation of constantly coming up with new ideas without considering their feasibility or value. You should avoid three things:

1. Don’t come up with new ideas all the time. Keep your record, write down your ideas, and try to find ways to validate them before bringing them to your manager or your colleagues. Adapting to the culture of your organization, you may need to come up with something more mature or validated, or you may realize you need to quit to make it happen.

2. Don’t spend resources on your ideas early on. You must find ways to validate your ideas with as few resources as possible. Think about what you would do if you were an entrepreneur with a nice idea. Initially, it’s only you, maybe with some employees that share your passion. The best way to gain traction is to create a story and start pitching it, and you can ask for resources to run some validations.

3. Don’t expect the ideas to be necessarily yours. You are in a position where you communicate with so many people in the company, you get signals, ideas, and context. It is equally important if you identify a good idea, work on it, and amplify the message; You should be the one knowing how to work on a new idea.

Some general principles to increase your creativity are:

• Create slots in your calendar just to think or read.

• Try to disconnect from day-to-day things to come up with new ideas,

• Look for ways to try and validate your ideas without annoying many people.

• Keep a physical notebook with your ideas.

• Don’t forget to get into customers’ shoes.

Data, Lack of data, and Product Sense

When you start a new product, you are lucky if you have some data to back you up. Thus, you have to start with qualitative data from customer interviews, form your vision, define deliverables, validate them and iterate; you should study the competition, start with Why and define clearly the problems you want to solve, and then define the segments you start from.

To do that, you need to develop a Product Sense, and a good way to do it is by exposing yourself to a variety of products and experiences, both within and outside your field. Try also to figure out which is the core value of the company and you may define a new experience that highlights and drives users to this core service.

Additionally, collaborating with people from different teams and backgrounds inside your organization can provide valuable insights into your concepts' feasibility and potential risks. You should try to share the problem, not lock them with the solution upfront, and you should ask for early feedback about the feasibility and the risks of your ideas.

Your Business Model is your Product

When you launch something from scratch, the business model is your product. You have to think about the whole experience, including the price, the channels of delivery, the segments, and everything. You should always have in mind two very useful tools, the Business Model Canvas and the Lean Canvas.

You may want to think of a business model innovation (e.g., new financial structure, new marketing channels), but you should also not forget the core product value you will offer. The user experience is something we all love to mention, unfortunately, it is easily copied once you launch, thus you have to think of something unique that will give you a serious head start; do you have access to a network, some unique data, or an algorithm? What’s your Unique Value Proposition and your moat?

Storytelling & Pitching for clarity

There is no better way to explain a new business model than by telling a story. To improve your skills you should read User’s Journey and Presentation Zen, or visit my previous post.

And of course, you can study all the great pitches from amazing Product guys. You should learn to tell a story, pitch it verbally and visually, refine it and understand how your audience reacts. Don’t be afraid to pitch your idea, then it will be easier to write it down as well.

Working backwards for alignment

At some point, you have to align many people under your idea, to get funding and approval, find a team, and kick off the development eventually. You have to start moving things around. There are no better tools for that than Amazon’s Six-Pager and Press Release, as explained in Working Backwards. Write down proper documents, circulate them with people you respect their opinion, and at the end pitch your ideas through a Six-Pager. You may need to pitch your idea through a slide deck, but a Six-Pager is some amazing material to follow even in that case.

Working on Iterations

Once you have done a thorough study and worked with your teams, you are ready to execute. Define your upcoming release, find a way to validate it early, and work with your team on iterations. You can define a mock type as explained in Empowered, or work on some prototypes and validations as described in Sprint. When you are ready, you should write a Press Release to be sure that everyone has the same understanding of what will be created.

You should frequently align with your previous work, are you misaligned with your initial hypotheses? Why? Is the whole business model at risk? Is the story you tell validated through your trials? You have to realize that the steps described above should run in iterations. Unless your story is smooth and engaging,

In practice, it’s hard

It's worth noting that being creative doesn't mean that you should ignore data or objective decision-making. It's important to balance creative thinking with analytical thinking and use both to inform your decision-making as a product manager. But what I am missing is more people in product coming up with ideas.

If you think about how many steps and efforts are needed to launch a new product successfully, you understand why people choose not to be creative; it’s so much energy, with a big risk of failure and disappointment.

This is a problem the Lean mentality has tried to fix; it has removed the complexity of launching a new idea by motivating you to break your work into smaller deliverables, while the cost of failure seems smaller. Yes, taking your highest risks and validating them with minimum effort is amazing, if you can do it. But hypothesizing that positive feedback for a prototype from early adopters is also a market fit can create even bigger problems for the organization, in a matter of product, tech debt, and the wrong culture, believing that you can run a business “cheap” without all the necessary components.

Overall, this is not an article sharing the path to success. The execution is much harder, each case is unique, and success cannot be guaranteed. You should start working on your path into more creative Product Management, this is my advice. And through trials, failures, and teamwork you can start becoming more creative; it is a skill you can build and develop.

My questions were definitely directed and focused on some of the most challenging topics, and many questions were not complete for sure; however, I can say that the answers were quite impressive, and I am happy that they are reaching a level of standardization for a challenging craft.

Below you will find our interview, feel free to run your own interview here. At least with ChatGPT, no one has excuses for not understanding or knowing what a Product Manager is and does…

Q - What is a Product Manager?

AI- A product manager is a professional who is responsible for the development and success of a product or product line. This can include defining the features and functionality of the product, setting pricing and marketing strategies, and working with a team of engineers, designers, and other stakeholders to bring the product to market. The product manager is often the key decision-maker and leader for a product, and they play a crucial role in ensuring that the product meets the needs of the target market and delivers value to the customer.

Q - Why is a Product Manager necessary today?

AI - A product manager is necessary today because the development and success of a product require a coordinated effort from a diverse team of individuals with different skills and expertise. The product manager serves as the leader of this team, ensuring that everyone is working towards a common goal and making key decisions about the product's direction and strategy. This is especially important in today's fast-paced, highly competitive business environment, where the success of a product can make or break a company. Additionally, the product manager plays a crucial role in gathering and analyzing customer feedback, which is essential for developing products that meet the needs of the target market.

Q - What are the responsibilities of a product manager?

AI - The responsibilities of a product manager can vary depending on the specific organization and the product they are responsible for. In general, however, the product manager is responsible for overseeing the development and success of a product or product line. This can include defining the product's features and functionality, setting pricing and marketing strategies, and working with a team of engineers, designers, and other stakeholders to bring the product to market. The product manager is also responsible for gathering and analyzing customer feedback to inform product development, as well as tracking and reporting on key metrics to measure the product's performance. Additionally, the product manager may be responsible for managing budgets and resources, and for making key decisions that affect the product's direction and success

Q - How is a Product Manager different from a Project Manager?

AI - A product manager and a project manager are both responsible for overseeing the development and success of a product or project. However, there are some key differences between the two roles.

First, a product manager is focused on the long-term success of a product or product line, while a project manager is focused on the successful completion of a specific project. A product manager is responsible for defining the product's features and functionality, setting pricing and marketing strategies, and making key decisions about the product's direction. A project manager, on the other hand, is responsible for planning and executing a project, ensuring that it stays on schedule and within budget.

Second, a product manager is typically more involved in the strategic direction of a product, while a project manager is more focused on the day-to-day management of a project. A product manager is responsible for understanding the needs of the target market and ensuring that the product meets those needs, while a project manager is responsible for managing the project team and coordinating their efforts.

Finally, a product manager often has a broader scope of responsibility than a project manager. A product manager may be responsible for multiple products or product lines, while a project manager is typically only responsible for a single project. Additionally, a product manager may have more direct involvement with other departments and stakeholders, such as sales, marketing, and engineering, while a project manager typically only works closely with the project team.

Q - How can you learn from Product Management failures?

AI - Learning from product management failures can be a valuable experience for product managers and teams. To learn from product management failures, it is important to carefully analyze the reasons for the failure and identify any key lessons or takeaways that can be applied to future product development efforts.

Some key steps for learning from product management failures include:

1. Identify the root causes of the failure: To learn from a product failure, it is important to understand what went wrong and why. This may involve conducting a thorough analysis of the product, the market, and the competition, as well as gathering feedback from customers and other stakeholders.

2. Understand the impact of the failure: The impact of a product failure can be significant, affecting not only the product itself but also the company and its stakeholders. Understanding the impact of the failure can help identify areas for improvement and provide insights into how to avoid similar failures in the future.

3. Develop a plan to address the failure: Once the root causes and impact of the failure have been identified, it is important to develop a plan to address the issues and prevent future failures. This may involve implementing new processes, strategies, or technologies to improve the product development process and ensure that future products are successful.

4. Communicate and share the lessons learned: Sharing the lessons learned from a product failure with the broader product team and organization can help ensure that the mistakes made are not repeated and that the team is better equipped to avoid similar failures in the future. This may involve creating a report or presentation that outlines the key takeaways and recommended actions.

Overall, learning from product management failures can help product teams and organizations improve their processes, avoid common pitfalls, and increase the chances of success for future products.

Q - How does a Product Manager interact with a Tech Leader?

AI - A product manager and a tech leader are both responsible for ensuring the successful development and launch of a product. As such, they need to work closely together and maintain a strong relationship in order to achieve their shared goals.

The product manager is responsible for defining the product's features and functionality, setting pricing and marketing strategies, and making key decisions about the product's direction. The tech leader, on the other hand, is responsible for overseeing the technical aspects of the product, including the development of the technology, the integration of different systems, and the deployment of the product.

To effectively interact with a tech leader, a product manager should:

1. Understand the technical aspects of the product: As a product manager, it is important to have a good understanding of the technical aspects of the product, including the technology and systems that are being used. This will allow you to have informed discussions with the tech leader and provide valuable input on technical decisions.

2. Communicate clearly and regularly: Effective communication is key to maintaining a good relationship with the tech leader. It is important to regularly communicate with the tech leader to share updates, discuss progress, and address any issues or challenges.

3. Collaborate on technical decisions: As the product manager, you are ultimately responsible for making key decisions about the product. However, it is important to involve the tech leader in these decisions and seek their input and expertise, especially when it comes to technical matters.

4. Support the tech leader and their team: The tech leader and their team play a crucial role in the development and success of the product. As the product manager, it is important to support the tech leader and their team by providing the resources, guidance, and support they need to do their job effectively.

Overall, by understanding the technical aspects of the product, communicating regularly and clearly, collaborating on technical decisions, and supporting the tech leader and their team, a product manager can effectively interact with a tech leader and help ensure the success of the product.

Q - How does a Product Manager interact with a Product Designer?

AI - A product manager and a product designer are both responsible for ensuring the successful development and launch of a product. As such, they need to work closely together and maintain a strong relationship in order to achieve their shared goals.

The product manager is responsible for defining the product's features and functionality, setting pricing and marketing strategies, and making key decisions about the product's direction. The product designer, on the other hand, is responsible for creating the visual and user experience aspects of the product, including its user interface, user flows, and overall aesthetic.

To effectively interact with a product designer, a product manager should:

1. Understand the design process: As a product manager, it is important to have a good understanding of the design process, including the tools and techniques used by product designers. This will allow you to provide valuable input and feedback on the design of the product.

2. Communicate clearly and regularly: Effective communication is key to maintaining a good relationship with the product designer. It is important to regularly communicate with the product designer to share updates, discuss progress, and address any issues or challenges.

3. Collaborate on design decisions: As the product manager, you are ultimately responsible for making key decisions about the product. However, it is important to involve the product designer in these decisions and seek their input and expertise, especially when it comes to design matters.

4. Support the product designer and their team: The product designer and their team play a crucial role in the development and success of the product. As the product manager, it is important to support the product designer and their team by providing the resources, guidance, and support they need to do their job effectively.

Overall, by understanding the design process, communicating regularly and clearly, collaborating on design decisions, and supporting the product designer and their team, a product manager can effectively interact with a product designer and help ensure the success of the product.

Q - How can a PM collaborate with Business effectively?

AI - A product manager can collaborate effectively with the business by taking the following steps:

1. Understand the business goals and objectives: To effectively collaborate with the business, a product manager should have a good understanding of the business goals and objectives. This will allow the product manager to align the product development efforts with the broader goals of the company and ensure that the product is contributing to the success of the business.

2. Communicate regularly and clearly with the business: Effective communication is key to collaborating with the business. It is important for the product manager to regularly communicate with the business stakeholders to share updates, discuss progress, and address any issues or challenges. This can help ensure that everyone is on the same page and that the business stakeholders are aware of the product and its development.

3. Seek feedback and input from the business: As the product manager, you are ultimately responsible for making key decisions about the product. However, it is important to seek feedback and input from the business stakeholders, as they may have valuable insights and expertise that can help inform your decisions.

4. Collaborate on key business decisions: To effectively collaborate with the business, the product manager should be involved in key business decisions that impact the product. This may involve providing input and expertise on topics such as pricing, marketing, and sales strategies, and ensuring that the product is aligned with the business goals and objectives.

Overall, by understanding the business goals and objectives, communicating regularly and clearly, seeking feedback and input, and collaborating on key business decisions, a product manager can effectively collaborate with the business and help ensure the success of the product.

Q - How can a Product Manager manage up?

AI - Managing up refers to the process of effectively working with and communicating with one's manager or higher-level leadership. As a product manager, managing up can be an important skill to have, as it can help you align your work with the goals and priorities of your organization and ensure that your manager and other stakeholders are informed about your progress and challenges.

To effectively manage up, a product manager should:

1. Understand the goals and priorities of the organization: To effectively manage up, it is important to understand the goals and priorities of the organization. This will allow you to align your work with the broader objectives of the company and ensure that your efforts are contributing to the organization's success.

2. Communicate regularly and clearly: Effective communication is key to managing up. It is important to regularly communicate with your manager and other stakeholders to share updates, discuss progress, and address any issues or challenges. This can help ensure that everyone is on the same page and that your manager and other stakeholders are aware of your work and the impact it is having.

3. Seek feedback and input: As a product manager, you are ultimately responsible for making key decisions about the product. However, it is important to seek feedback and input from your manager and other stakeholders, as they may have valuable insights and expertise that can help inform your decisions.

4. Be proactive and take initiative: To effectively manage up, it is important to be proactive and take initiative. This means anticipating potential challenges and opportunities, and taking steps to address them before they become problems. It also means being willing to step up and take on additional responsibilities or challenges when needed.

Overall, by understanding the goals and priorities of the organization, communicating regularly and clearly, seeking feedback and input, and being proactive and taking initiative, a product manager can effectively manage up and ensure the success of their product and their team.

Q - When is the best time for a startup to hire its first Product Manager?

AI - The best time for a startup to hire its first product manager can vary depending on the specific needs and goals of the company. In general, however, a startup may want to consider hiring a product manager when it has identified a product or market opportunity and is ready to start developing and launching a product.

At this stage, the startup may benefit from the expertise and leadership of a product manager who can help define the product's features and functionality, set pricing and marketing strategies, and coordinate the efforts of the product development team. A product manager can also help the startup gather and analyze customer feedback and market data, and make informed decisions about the product's direction and success.

Overall, the best time for a startup to hire its first product manager is when the company is ready to start developing and launching a product, and when it will benefit from the expertise and leadership of a product manager to help guide the product development process.

Q - How do you think the role of a Product Manager will evolve in the near future?

AI - The role of a product manager is likely to evolve in the near future as technology and the business landscape continue to change and evolve. Some potential ways in which the role of a product manager may evolve in the near future include:

1. Increased emphasis on data and analytics: As data becomes increasingly important in the product development process, product managers may need to develop stronger skills in data analysis and interpretation. This may involve using data to inform product decisions, track performance, and identify trends and opportunities.

2. Increased focus on customer experience: As competition in the market continues to increase, product managers may need to place a greater emphasis on customer experience. This may involve using customer feedback and data to improve the user experience and differentiate the product from competitors.

3. Greater collaboration with other departments: Product managers may need to work more closely with other departments, such as engineering, design, and marketing, to ensure that the product meets the needs of the customer and the business. This may involve coordinating cross-functional teams and fostering collaboration among different stakeholders.

4. Increased emphasis on agile and lean principles: As agile and lean principles continue to gain popularity, product managers may need to become more familiar with these approaches and incorporate them into their work. This may involve using agile and lean methods to manage the product development process, prioritize work, and deliver value to the customer.

Q - What makes a Product Manager successful?

AI - There are several key factors that contribute to a product manager's success. These include:

1. Strong strategic thinking and decision-making skills: A successful product manager is able to think strategically and make informed decisions about the product's direction and success. This may involve understanding the needs of the target market, analyzing customer and market data, and making decisions based on data and analysis.

2. Excellent communication and collaboration skills: A successful product manager is able to effectively communicate and collaborate with other team members, stakeholders, and customers. This may involve regular communication and updates, as well as the ability to persuade and influence others to support the product and its development.

3. Strong technical knowledge and expertise: A successful product manager should have a strong understanding of the technical aspects of the product, including its technology, systems, and architecture. This knowledge can help the product manager make informed decisions and provide valuable input to the product development team.

4. A customer-focused mindset: A successful product manager is focused on delivering value to the customer and meeting their needs. This may involve gathering and analyzing customer feedback, conducting user research, and making decisions that prioritize the customer experience.

Overall, a successful product manager is someone who has strong strategic thinking and decision-making skills, excellent communication and collaboration skills, strong technical knowledge and expertise, and a customer-focused mindset. These qualities can help the product manager lead the product development process and ensure the success of the product.

Q - How can a Product Manager become a Product Leader?

AI - A product manager who wants to become a product leader can take several steps to develop the skills and experience needed for this role. These steps may include:

1. Gaining experience and expertise in product management: A product manager who wants to become a product leader should strive to gain as much experience and expertise in product management as possible. This may involve working on a variety of products and teams, learning from mentors and peers, and staying up-to-date on the latest trends and best practices in the field.

2. Developing strong leadership and communication skills: A product leader needs to be able to effectively lead and motivate a team of product managers and other stakeholders. This may involve developing strong leadership and communication skills, such as the ability to inspire and motivate others, and the ability to clearly and concisely communicate complex ideas and information.

3. Building a strong network and reputation: A product leader should strive to build a strong network of contacts and colleagues in the product management field. This may involve attending conferences and events, joining professional organizations, and sharing insights and experiences with others in the field. A strong reputation as an expert and thought leader can also be valuable for a product leader.

4. Pursuing additional education and training: A product manager who wants to become a product leader may benefit from pursuing additional education and training in product management or related fields. This could include taking courses or workshops, pursuing a certification, or earning a graduate degree in product management or a related field.

Overall, a product manager who wants to become a product leader can gain experience

Q - How does a Product Manager contribute to a Go To Market Plan?

AI - A product manager plays a key role in developing and executing a go-to-market (GTM) plan. The GTM plan is a strategic plan that outlines the steps and tactics that a company will use to bring a product to market and achieve its sales and revenue goals.

As the product manager, you can contribute to the GTM plan in several ways, including:

1. Defining the product's features and functionality: As the product manager, you are responsible for defining the product's features and functionality. This information is critical for the GTM plan, as it provides the basis for the product positioning, pricing, and marketing strategies outlined in the plan.

2. Conducting market research and analysis: As the product manager, you should have a good understanding of the market and the target customers for the product. This knowledge can be invaluable when developing the GTM plan, as it can help inform the product positioning, messaging, and sales and marketing strategies outlined in the plan.

3. Collaborating with the sales and marketing teams: As the product manager, you should work closely with the sales and marketing teams to develop and execute the GTM plan. This may involve providing input and guidance on the product positioning, messaging, and sales and marketing strategies outlined in the plan, and ensuring that the product is ready for launch.

4. Tracking and measuring the success of the GTM plan: As the product manager, you should also be responsible for tracking and measuring the success of

Q - Is pricing a task for product managers?

AI - Pricing is typically one of the tasks of a product manager. As the product manager, you are responsible for defining the product's features and functionality, and setting the pricing and marketing strategies that will be used to bring the product to market.

When setting the pricing for a product, the product manager should consider a variety of factors, including the cost of producing and distributing the product, the target market and competitors, and the perceived value of the product to the customer. The product manager should also consult with other stakeholders, such as the sales and marketing teams, to ensure that the pricing strategy is aligned with the broader goals of the business.

Overall, pricing is an important task for product managers, as it is a key factor in the success of the product and the business.

Q - How product discovery and validation are relevant for a Product Manager?

AI - Product discovery and validation are critical activities for a product manager. These activities involve identifying the needs and preferences of the target market, and testing and refining the product concept to ensure that it meets the needs of the market and has the potential for success.

As a product manager, you are responsible for driving the product discovery and validation process. This may involve conducting market research and user research to understand the needs and preferences of the target market, and using this information to develop and refine the product concept. It may also involve conducting user testing and gathering feedback from potential customers to validate the product concept and ensure that it is viable and desirable.

Overall, product discovery and validation are crucial activities for a product manager, as they help ensure that the product is aligned with the needs and preferences of the target market, and has the potential for success. By driving these activities, the product manager can help ensure the success of the product and the business.

Q - Why people don't understand easily Product Management?

AI - There are several reasons why people may not understand product management easily. These reasons may include:

1. Product management is a relatively new field: Product management is a relatively new field, and as such, many people may not be familiar with its principles and practices. This lack of familiarity can make it difficult for people to understand product management and its importance to the success of a product and a business.

2. Product management is a complex and multifaceted role: Product management is a complex and multifaceted role that involves many different responsibilities and skills. This can make it difficult for people to understand the scope and depth of the product manager's role, and how it fits into the broader product development process.

3. Product management is often misunderstood or confused with other roles: Product management is often misunderstood or confused with other roles, such as project management or product design. This can lead to confusion about the product manager's responsibilities and how they differ from those of other roles in the product development process.

Overall, these factors can make it difficult for people to understand product management and the important role that product managers play in the success of a product and a business.

Q - Tell me a joke about Product Management

AI - Why was the product manager always calm?

Because she had a backlog of problems!

Q - Tell me the top 5 books for Product Management

AI - The top 5 books for product management are:

1. "The Lean Startup" by Eric Ries: This book provides a framework for developing and launching new products in a lean and agile manner. It covers key concepts, such as the minimum viable product and the lean canvas, and provides practical guidance for product managers.

2. "Inspired: How to Create Tech Products Customers Love" by Marty Cagan: This book provides a comprehensive guide to product management, covering topics such as product vision, strategy, and design. It also includes practical advice and case studies from experienced product managers.

3. "The Innovator's Dilemma" by Clayton M. Christensen: This book examines the challenges that companies face when trying to innovate and stay ahead of the competition. It provides valuable insights for product managers on how to navigate disruptive technologies and markets.

4. "The Art of Product Management" by Sunil Prashara: This book provides a comprehensive overview of the product management discipline, covering key concepts, techniques, and tools. It also includes case studies and practical advice from experienced product managers.

5. "User Story Mapping" by Jeff Patton: This book provides a practical guide to using user story maps to plan and manage the product development process. It covers key concepts, such as empathy mapping and iteration planning, and includes practical exercises and examples.

Q - Tell me the top 5 Twitter accounts about Product Management to follow.

AI - The top 5 Twitter accounts about product management to follow are:

1. @ashmaurya - Ash Maurya is the author of "Running Lean" and "Scaling Lean" and a renowned expert on lean startup and product management. His Twitter account provides valuable insights and advice for product managers.

2. @cagan - Marty Cagan is the author of "Inspired: How to Create Tech Products Customers Love" and a leading expert on product management. His Twitter account offers valuable insights and advice for product managers.

3. @BrennanDotDev - Brennan Dunn is the founder of RightMessage and a thought leader on product management and marketing. His Twitter account provides valuable insights and advice for product managers.

4. @pmarca - Marc Andreessen is the co-founder of Andreessen Horowitz and a leading venture capitalist and technology entrepreneur. His Twitter account provides valuable insights and advice for product managers.

5. @jeremywaite - Jeremy Waite is the Chief Digital Evangelist at Salesforce and a thought leader on product management and marketing. His Twitter account offers valuable insights and advice for product managers.

When you run your own business, you own the idea and the resources, to realize soon you can’t do everything on your own. You learn how to be a doer, while you value and evaluate the contribution of each stakeholder. Thus, it is one of the best opportunities where you can learn your limits, your skills and weaknesses, and realize what needs to be done to build a business, with or without a product.

What ex-entrepreneurs have

When you are a PM, one of the main challenges you face is that you are leading a product team without reporting to you (typically); You need a budget, but you are not responsible for the resources. You are in the middle of multiple business functions and need to lead them into a creative and productive process. You have to look at the big picture and own the outcome.

Things you learn as an ex-entrepreneur:

• You learn to pitch. As a business owner, you are naked to the ones you sell a story to. If you have mastered this skill, you can inspire your team and influence decision-makers and stakeholders more easily. If you don’t have to support a new idea and get approval and funding, you don’t know the pain. These are skills a PM who landed or switched to an existing business or product is missing and needs to develop.

• You are resource-thoughtful. As an ex-entrepreneur, you learn to act with a shortage of resources and trade-offs you have to make. You learn to mock without guilt, and you can turn this into a super-power to convince people. Based on the lifecycle of your product, you can plan and communicate in advance about what you need, because you have experienced the pain. I have seen PMs having Design Researchers, UX Designers, Product Designers, Business Analysts, Data Engineers, Data Researchers, and of course Engineers, without knowing what to do with them. Of course, you can learn this skill while in a company, but you will need it if you are in a growing organization.

• You know how meeting clients is. What is a cold email and how do you write one? How tough and time-consuming is it to schedule and run a meeting? How important are preparation and a good demo? Have you managed pressuring or indifferent clients? If you have experienced that, you will appreciate the power of your company’s brand and you will see how managing your clients’ relationship is an art. Above all, you will understand why, how, and when the business guys need to make promises; they either want to make the deal happen or feel weak and uncomfortable. Empathy with business is something you need to develop.

• You learn that you need to be a leader. If you pay your team on your own, you realize that salary is not the only way to get what you want from them. You need to inspire them, support them, and celebrate with them the wins, but also to isolate toxic behaviors and underperformers. Soon, you realize that if you have no leadership traits, apart from management characteristics, you can’t do much progress.

• You become a team player. You need to live with your weaknesses and realize when you have to delegate. You have built things on your own, you have messed up, so you can recognize good contributors and you can manage them more effectively.

And indeed, some of my best hires were people belonging to that group. In the Product world, you will hear someone calling it “ownership”. But how can you have ownership when you haven’t tried to build something on your own? Yes, you can use data to validate your decisions, you can copy competition and follow the corporate strategy while you learn the industry, and you can be a great corporate PM. But definitely, you haven’t launched the business you operate in and you don’t know what it takes to potentially launch a new business.

Yes, but

There has been a discussion among the Product Community about the difference between zero-to-one or early-stage startup PMs, compared with Growth PMs or big-tech PMs. I can understand that people within a big corporation with its own processes and systems, an established structure with strong politics, cannot easily act as end-to-end owners. I really believe that the skills described before are useful, but the ex-entrepreneurs have also some weaknesses:

• Growth PMs have specialization. Ex-entrepreneurs are generalists, and they may not pay attention to the details. When they switch to a more established environment they may struggle initially. With the proper guidance and management they can adapt, but they may feel a misfit for a while. Their managers need to pay more attention.

• Big ego or free spirit. Ex-entrepreneurs may be frustrated while working in a corporate environment. Some of them may have been entrepreneurs because they had the need to create or they had a nice idea, but there are cases where they cannot fit into a team, and they go alone. This case is irreversible and you need to filter them out of the process as they will create a toxic environment.

• They tend to micromanage. When someone has done “everything” to deliver, they may be judgemental on how something should be done. This micromanagement tendency will create problems within the team. This can be solved by working on the ex-enterpreneur’s management skills, to realize that they have to add quality and outcome validations and not managing the steps, and they need support from their managers.

So, is it a prerequisite?

No. In the end, it is also what the organization wants and needs. There are organizations giving full control to PMs. There are other cases where a business owner runs the business unit, and the PMs run the product. Based on the size, goal, and structure of the company, the impact of an ex-entrepeneur as a Product Manager may vary. Still, a PM who can show entrepreneurial characteristics can excel in her career, and you definitely have two rare traits:

1. You have someone that has launched a project end-to-end and has learned why building fast is important and how it may break.

2. You have someone that knows with whom you have to talk to get something done, and manage the dependencies more effectively.

For these reasons stated before, despite the initial difficulties that ex-entrepreneurs face while switching to Product Management, I consider them some of the best Product Managers I have met and some of the best hires I have made. It is a hiring tactic, and it is worth trying at least once in your product leader career.

There is no ideal moment to join a startup as a product manager or leader; if it is a startup, you should expect to struggle against the unknown on seeking market fit while growing organizationally.

Everyone would like to join a startup run by an ex-product-driven entrepreneur, but this is not common, at least in Europe, especially Greece. Thus, you shouldn’t expect to find a ready-to-work environment, and part of your job will be to train people and build a product culture within the organization's limits.

Good Signals

It would be nice to recognize a “good startup” to join as a Product person. Ideally, a promising startup to join has:

1. A Product that you understand and preferably like. You should play with the product (have a demo if it’s B2B), talk with the team you are about to join, and understand if what they describe is what they have been building. Try to understand the unique advantage, don’t rush to raise your concerns, and try to listen.

2. A passionate Team that can align with your views. You should put more emphasis on the people you will work together, aka the engineering, sales/business, and operations counterparts for your role. Of course, your manager (or the CEO) is also essential, but you need to work with a team on the same level, or you will have to help build the missing counterparts.

3. A good Financial state means having a break-even or having secured the required funds to run for at least 2 years. Financial pressure creates anxiety, anxiety blurs judgment, and people turn to their instincts or rationalizations. Working in a startup will be a ride, but it doesn’t have to be tough. The company's age, any strange acquisitions, the number and size of investing rounds, and the number of people are indications of its financial state.

4. Tech understanding, tech people, and excellence should be evident in the way of thinking. Try to recognize and avoid people talking about “tech” but not “products” or about “engineers that don’t get it and are spoiled” but not about product teams; they probably consider “tech” a cost center, and you will have to explain all the team how teams should work to create additional value with products.

5. They have a Vision, and you like it. You and the teams need inspiration and somewhere to link the strategy and the actions; if there is traction, the vision can be a catalyst for successful growth, the north star when decisions are tough. If you don’t like where the startup is heading today, you probably won’t like it later; if someone gets a consultant to build a vision, nothing will change. The vision and actions that prove that teams are working to achieve it are empowering and will make your life more pleasant.

6. Business people or co-founders who talk about Customer needs and customer-oriented thinking. You should dive into how they get feedback and how they apply it. You should avoid people talking about “stupid users” to point out their intelligence.

Bad Signals

Things that are red flags for me :

1. Co-founders with big ego. It is part of your job is to educate and manage up, but it will be a toxic environment even if the company gets successful. To recognize it, you should spend some time together and try to realize if you feel comfortable with how they talk and behave.

2. Big promises. People talking about fast growth without a straightforward offering and an apparent problem, talking about building the next Google and Apple.

3. Avoid business people talking about money, evaluations, rounds, and market size while stating how stupid competition is, knowing the market exceptionally well, and opening doors with customers like no other. It will be tough to collaborate with people who know everything about the market and don’t want to talk with anyone.

4. Being fuzzy about stock options plans and the terms. You can be optimistic you will find a way, but people get greedy as they face success. A company that grows beyond 10 people must have clear and transparent governance, and your deal is based on what’s the stock plan too.

Neutral Signals

Things that I don’t emphasize even if I consider them and try to understand more through discussion:

1. Selling Services instead of Products. This is tricky. If a company has raised money to build products and does custom services that don’t scale, it will soon go into tough times with the investors. If they are in the beginning or bootstrapped, it may be a wise tactic to go into a market and get validation before they build something that scales, especially in B2B.

2. Designs of the product. We all like products with lovely designs. Instead, you should try to understand why customers use the product even if it is not nice-looking. The value is elsewhere in the early stages. On the other hand, a big team without “aesthetics” or confusing design signals that you will have some work to do in that direction.

3. Website. I have worked for B2B companies that made money even with an awful website. What is annoying is that you can’t understand many things, and you have to make more questions to understand what’s all about.

4. Awards. No one should care about awards when joining a company.

Product Questions to ask

Below, I list an extensive but not complete list of questions you can ask while discussing joining a startup. My advice is to avoid calls if possible, you should be able to visit the offices physically and talk in person with the team, at least in the latest stages of the communication.

1. “Who runs the product today?” Typical answers are “we are doing it all together”, “we have promoted someone from the [x] department,” or “the [y] co-founder(s)”. Based on the answer, you can understand when you will need to focus and potentially ask to talk with these people.

2. “What’s the size of the engineering team?” You should know the ratio of the engineering, as it is an indication of company strategy if they grow through tech or sales.

3. “Who talks with the customers today?” If the teams already have access to customers, it’s great. Otherwise, you have to meet the sales/business guy and see if you can work together. Also, you should understand if they look for confirmations or if they actually look for customers’ problems.

4. “What do you expect from a product team within the company?” If you get an answer like “I want you to become the CPO next to me,”it is translated as “I have no idea what the product is about, but you will build what I want”. Typically you should see someone recognizing their pains, understanding that they have reached a ceiling with product management and need an expert to take over.

5. “How do you decide about what will be built?” Early stage, you expect the co-founder to be this guy. If the answer is similar for a larger organization, this is a bad sign you must discuss it in detail before you join.

6. “Who is responsible for the architecture?” If you are lucky, they will understand what a product architecture is, and possibly some of the cofounders will do it. The most prominent answer is “[x] from engineering”, confusing the product with the tech architecture, which is ok, it shows an engineering mindset. It is also possible that you get no answer; this is not a tech or product-driven company.

7. “Who is responsible for delivery?” This question exposes the engineering seniority and the organization's maturity. If you get an answer like “the co-founder or the PM”, you have to change things to explain that engineering must be accountable for the output.

8. “How do you work with engineers? Do you have any framework?” This is the question that you can make you understand if engineering is a cost center or value creation factor.

Additional questions to ask

Apart from understanding the product mindset of the team, you should learn more about the organization.

1. “What’s your ARR” and “Have you/When do you expect to break even?” You can understand the financial strategy.

2. “Why are you better than the competition?” You need clear, non-emotional answers. Ego may rise here.

3. “What’s your vision for the company?” You will be surprised at how many bad questions you will get. If you don’t like the answer, people within the company won’t like it too.

4. “What’s your strategy to grow the company?” Typically the answer you will get is not about strategy. It’s tactics, operational, or some buzzwords.

5. “How frequently do you sync?” and “Do you work remotely or at the office?” As remote and hybrid are parts of our life, you should know if this model fits your needs. I like face-to-face syncs where traveling may be required.

Don’t make it look like an interview

You should ask for an interview with casual face-to-face meetings, while you should meet various people from the team, not only the hiring manager or the co-founder. Don’t go through a list of questions, it will be like an investigation, and people won’t like it, as you wouldn’t like it either.

Also, this is not a quiz. “Bad answers” are not the end of the world. You should weigh the importance of each criterion for you and understand that often it is part of your job to fix the problems you identify. Still, you must understand if the organization is willing to change and improve, this is the most critical question to answer.

You need to understand if you can work together with these people and which cultural, financial, market, and organizational limitations you may face.

Part of your job is to educate the organization if needed, build a structure and drive the company into a new era. Hopefully, the company has been building a product and an engineering culture, making it easier to apply standard practices. Don’t get scared by companies that are not product thinkers or if they sell services; It’s about your expectations, your energy, and your belief that this relationship is going to work.

I am happy to learn if this article is helpful for you and how you go into discussions with startups to choose the next step in your career.

1. The missing bridge - How to communicate an idea to decision makers to get buy-in without needing to build staff to prove their position.

2. The missing glue - How to keep a team engaged while building a product without delivering a broken experience or needing to define every detail early on.

The frustration on PMs’ faces was visible when I tried to explain that it was unclear to me where they were heading and why. The video below highlights how tough it is to communicate your ideas when there is not something tangible; it is tough to visualize it, or it is misinterpreted.

The quick answer I got was, “let’s build some wireframes,” but this is sometimes costly, tiring, and short-looking and some screens are not the whole customer experience. What I was advising them was to become storytellers, and they were pretty surprised when I asked about it.

A customer experience is a service and it is the superset of the product the team is building. Product leads, onboarding, back-office services and customer support is part of the experience and must be taken into consideration by every Product Manager.

When you build a product, you have to be in the position to communicate where the product is heading within the next 2-3 years without needing to build things that will cost you time and resources; no worries, everyone expects things will change, and learnings will alter the plan within this period.

Becoming a storyteller

Storytelling is the “superpower” for Product Managers to address many internal communication challenges. Building a good story raises questions about the user context and challenges the PMs to think with user flows and not static outputs, why users have decided to use their product, and how they get the value that will make them keep coming back.

The goal of a story is not only to describe the final state (i.e., a feature or a screen) but to describe all the intermediate steps to reach that point. A good story needs proper user context, a clear description of the struggle and the user's pain, and a spike, a wow moment that will impress the audience. A good story has to stick, and it has to escalate progressively. You can read a fantastic book about the power of storytelling here, it is worth it.

When creating a story, I don’t simply start writing a document; I need to include my team(s) to build a standard view and get our time to think. Thus, typically I start with building a user journey mapping or running a Design Sprint with the help of a product designer. From the multiple paths of a user journey, we highlight the most prominent scenario that clarifies the value the product creates, and this is the story we are building. With multiple iterations, and the lead of a product manager, the team can create and update their main story highlighting the value of the product they are building.

Communicating a story

What was more tricky than expected early in my career was to communicate a user story and scenario, even internally. I had noticed that stakeholders might be critical about not covering the scenario they perceive as most prominent, or they thought that the stories were oversimplistic or naive; when they were part of the process, it was easier to communicate it, but it is not always feasible to have every stakeholder in a design sprint.

What I found more helpful in communicating a story, even if it was written as a story arch with plain text, was the usage of two tools:

1. A Press Release (PR) document - or any relevant “working backward” document (e.g., customer letter) - allows communication of what the customer perceives and challenges you to share the whole product offering, including price and positioning.

2. A vision type for more strategic decisions allows the audience to start seeing what a PM has in her mind; it requires more time to be built, but it should be selected for strategic, long-term decisions that will cost even more if executed.

The final document could be a 6-pager, with additional details (e.g., tech details, market insights) and a list of the most common questions in a well-thought Q&A section. The PR document can be in the Annex, with a vision type, a live demo, or a link to a video. A 6-pager is something tangible that can be shared more efficiently, and feedback can be more thorough.

Having a good story is not enough.

The process of storytelling is iterative. A story creates a Press Release or a vision type, which initiates an action plan, and the team's findings may update the story. Thus, having a nice story doesn’t mean that you have taken approval.

What is needed is an action plan with a clear owner to start executing, and what is required to launch is the right time to ask. A PM has to work closely with the key stakeholders on that phase, and the story, of course, is a map but not the ultimate goal.

In the end, a product experience is something everyone should try; just ride the user journey as described in your story, and you can feel if it makes sense for you or if something feels weird and broken.

Let’s say that the analysis is complete, or to put it better, you have focused on an opportunity that looks promising. How do you start looking for solutions?

It is critical to consider valid options to drive and debate with your team to start doing your early validation. So, how don’t you look like being into paralysis by analysis or being “too B2C” on your ideas?

I believe the best recap of available frameworks to choose where you prioritize is available in the Lean Analytics book. But as I tried to use them, I found them “too B2C”. When you work on B2B, data-related, bulk action products, the rules on how you can generate value for your clients change. Through the years, I developed my own ideation matrix called “APRIOrI” to help me generate potential solutions for B2B products. I have used it for years, and I would like to open it for debate to understand if it can be useful for more teams.

APRIOrI - Building B2B products

APRIOrI (inspired by apriori analysis) is about prioritizing the jobs of your B2B users so that you amplify the value your product may generate. Before you go into the solution validation or use other prioritization frameworks (e.g. RICE, MoSCoW), you hypothesize :

• Automate - Can you automate tasks your users do? Such features can create new revenue for your clients; at least, they should be able to save time and reduce costs. Try as early as possible to automate things, and reduce the manual processes for users. For example, if you are a fraud detection system, you should automate a big part of the transactions.

• Prioritize - What cannot be automated should be prioritized for human validation and review, so you should help users have a greater impact with their actions. This includes giving filters and options to your operations or users to find the most effective way to run through a list of tasks. For example, a media service should review viral content first if the automated screening process doesn’t have a big accuracy score.

• Report - If your product is doing well, someone needs to know about it; At least, they will need to export the outcomes of your system. Thus, if you create value, you will soon need a reporting functionality. For example, generate a daily or weekly CSV with the outcomes, or build a web reporting tool with download functionality. Remember, CSVs are gold in business software because they can be used as input for other systems, including spreadsheet analyses.

• Integrate - Having a good product, your users will need to integrate it deeper into their operations; they already use quite a big set of tools, starting from their email. So, can you generate additional value by integrating with one of their existing tools? This could even be a plugin on their Chrome Browser to pass data from your tool to/from their business tool. E.g., Atlassian can turn an email into a ticket, or Expensify is integrated with your email or Uber business account.

• Organize - B2B software typically includes the management of teams. People need to allocate tasks, review actions, generate reports and have roles with permissions. As your automation will amaze your clients and allow them to scale their operations, they need to align with their internal policies. If you are lucky, your clients will not ask about this early on. So, when they need more people to use your product, they will start asking for more sophisticated permissions or processes.

• Inform - With a stable tool and operations, your teams will ask for a more detailed operational analysis to extract knowledge and optimize their operations. This is the time for analytics, dashboards, etc. But also, this can be another offering or an existing BI tool. Don’t try to build everything on your product unless you have so much success that your users don’t need or want to leave your application.

Don’t forget, your product is an experience

Identifying a high-impact automation feature doesn’t mean you have a product; potentially, you are value-creating, which is amazing for a product. As your product grows (the product lifecycle) or if you need to address a more mature market (market adoption curve), you will need to focus on the whole experience of your product. You need to realize that to create a self-served, scalable and repetitive application, you need a set of features; it’s a matter of prioritization to meet the market-fit and bit competition.

Ideally, (a) if you achieve a level of automation and you can export the output of your system, you have created the minimum value of your product. Progressively, (b) you can allow your users to prioritize tasks, so they need to use the application to cover what cannot be automated. Then, (c) it will be easier for your users to use your product if it can collaborate with their existing ecosystem of solutions (don’t forget that import-export of CSVs is the minimum integration out there). Finally, as adoption of your product grows, you may be in the (d) pleasant situation to organize a set of teams to use your product more effectively, with the proper permissions. Lastly, or even in parallel, (e) as you want to beat the competition, your product will need to retain your users and inform them with more insightful metrics about their operational excellence.

However, don’t forget that these frameworks and tips are just a way of generating ideas and prioritizing. The final product is about the experience of the user while interacting with your product, and this includes a subjective view and the vision of the product team that builds the product. So, don’t blindly follow any framework presented, including mine; use whatever you like and is useful for your own analysis and thinking.

Why is this B2B related (mainly)?

As the dictionary says, apriori means reasoning which proceeds from theoretical deduction rather than from observation or experience. In the B2B world, where you have a limited pool of clients and input, and it is tough to ideate as your competition is typically the usage of the workforce or excel files, I have found that these practical rules have been helping on ideation. So, these areas of opportunities can be used as focus areas by B2B PMs to identify what problems are trying to address and understand the maturity of the product in its lifecycle.

These areas of idea generation may be useful for B2C PMs too, but in the client-facing world, awareness, conversion, and retention are important and well-defined areas of interest for the PMs, and there are multiple frameworks out there to follow.

Use RICE to align with Business & Ops

You should start with collecting every business and ops requirement. You can run an offline commenting process with deadlines to realize which are the stakeholders’ expectations. Don’t rush to go into a meeting room, see what they have to raise. In parallel, you should work with the Engineering Manager, and define the tech debt, and we enriched our backlog with them as well.

Here is the nice thing. For B2B, you can allocate each criterion to different stakeholders, in the following way (based on the number and type of stakeholders, you can adjust this):

• Reach is given to the business. They define how many clients are expected to be affected by these stories, based on their interviews. It is an opportunity to elaborate and share their insights. Business Intelligence working close with the team, can also clarify the reasoning behind this score.

• Impact is given to operations. They define how these features will allow them to meet their goals. If not a profit, they define a cost reduction. For a B2B company, the operations are a great source of feedback, otherwise, the PM should represent the users and the market. Of course, if the business can define the size of the opportunity, you can use it as well.

• Effort is given mainly to engineering. You should include also the PM and Product Design effort, especially since the latter is forgotten in cost and time calculation, while it is one of the first steps of the execution.

• Confidence is managed by you (the PM). Having listened to different opinions, and run your research, you can identify the maturity of an idea and you vote on the reasoning of the team members.

You can run this score-giving process in iteration. As you see big epics, you can break them down into smaller stories; The smaller the task, the easier it is to quantify, thus prioritize. You should not forget to ask for the score givers for quantitative and qualitative feedback so that you understand the context, and it’s important to expand your opportunities and be inclusive in that stage; You should not forget to define options that will put some extra “magic” to your planning. However, whatever the RICE score, you shouldn’t prioritize like this, you need to go into a workshop with your team.

RICE builds a Backlog, not a Roadmap

By now, you should have an ordered list of features in an excel file. Don’t get confused, this is not your Product Roadmap yet. And you should not design a voting mechanism for building a roadmap; until now you had been a facilitator, and now you start being the product manager that makes decisions.

To move forward, you should organize a product workshop. Start with defining the product goals for the next 3 years and agreed on the annual goals of the domain (the first day of a design sprint). Under this goal, you should identify the themes of the epics, aka the main pillars on which your roadmap will focus.

Under this context, you should start discussing the stories you have created and the given score, and the problem that each story tries to solve. As a PM, based on the discussion, you can adjust your confidence score.

At the end of the process, you have a prioritized backlog, based on the given RICE score. Now try to see about (a) dependencies, requiring a story to go higher in the priority, and (b) see if the stories that are higher in priority fit into the problems that you have identified as the most important for your product strategy and the goals you have set.

Finally, try to tell a story. If you can’t, you are missing potentially the big picture and you should go into a Design Sprint with your team before you start again working on Roadmapping. Don’t stay on any RICE score, any excel file, or something similar. If your story about your user experience doesn’t make sense, your backlog is incomplete and needs adjustments.

Being transparent builds trust

Try not to be biased in that process; the fact that you own the confidence score should challenge you more to clarify where there is uncertainty so that you and your team have a clear view. This backlog should be your prioritized list of opportunities and not a contract, which you manage as you get more insights and data, and potentially you may want to adjust your priorities. The best part of using this process is that you will have won the trust and the confidence of other departments and stakeholders, knowing that you have taken into consideration many different aspects, while you can communicate your vision and way of thinking clearly. Personally, I have seen the whole team dynamics change positively after the completion of this process.

Note: Sticking on frameworks is not ideal for Product Managers, you should look at how a framework fits your needs. This post explains how a well-known framework like RICE was found useful in the B2B world for me. As a team and an organization evolve, a framework may evolve into a culture, and you can use it in your own way. Feel free to share your own experiences with B2B prioritization, with or without RICE.