Tag: leadership

Posted on

John 21:5-6 and the Art of Asking Better Questions: Why AI Prompting Is Like Jesus Teaching His Disciples to Fish

“Then Jesus called out to them, ‘Friends, haven’t you any fish?’ ‘No,’ they answered. He said, ‘Throw your net on the right side of the boat and you will find some.’ When they did, they were unable to haul the net in because of the large number of fish.” (John 21:5-6, NIV)

The disciples had been fishing all night with nothing to show for it. Then Jesus, who they didn’t immediately recognize, asked one simple question that changed everything. Not “Why aren’t you catching fish?” or “Have you tried different bait?” Just: “Haven’t you any fish?”

That question led to instruction. The instruction led to abundance.

When someone struggles with AI prompting, they’re casting their nets over and over, getting frustrated with empty results, convinced the tool is broken. But like the disciples, they’re often fishing in the wrong spot with the wrong approach.

The art isn’t in the casting, it’s in learning to ask better questions and knowing where to throw the net. Obviously, the disciples knew how to fish and this story isn’t really about fishing, it’s about obedience and trust, but I’m trying to use a metaphor and I’m not really that good at them.

The Problem With Most AI Interactions

I see this pattern constantly. Users approach AI tools the same way they approach search engines: throw in some keywords and hope for the best. But AI isn’t Google. It’s more like a really smart intern who needs context, direction, and clear expectations.

The disciples were experienced fishermen. They knew how to cast nets, repair equipment, read weather patterns. Most people struggling with AI aren’t lacking technical skills, they’re lacking the right framing.

Jesus didn’t give them a fishing tutorial. He asked a diagnostic question, then provided specific direction: “Throw your net on the right side of the boat.”

That specificity matters. “Right side” isn’t arbitrary, it’s based on understanding conditions they couldn’t see from their position in the boat. Jesus had a vantage point they didn’t.

The Anatomy of Better Questions

When I work with teams on AI integration for sermon prep, the breakthrough moment isn’t technical. It’s when they stop asking “How do I make AI write my sermon?” and start asking “How do I help AI understand my congregation’s needs?”

The difference:

Fishing in the wrong spot: “Write me a sermon on forgiveness.”

Throwing the net on the right side: “I’m preaching to a congregation that’s 60% over 50, many dealing with family estrangement after the 2020 election divisions. They’re tired of political sermons but need biblical hope for restoration. Help me write a 20-minute sermon on forgiveness that acknowledges real hurt without being preachy, using Matthew 18:21-22 as the primary text, with two personal application points they can act on this week.”

The second prompt gives AI the context it needs to be helpful. Like Jesus with the disciples, it provides specific direction based on understanding the full situation.

Why This Matters for Digital Discipleship

The disciples’ empty nets weren’t just about breakfast. John tells us this story in the context of restoration, Peter’s reinstatement, the commissioning to “feed my sheep,” the establishment of early church leadership. The fishing miracle was functional, but it served a larger discipleship purpose.

AI in ministry works the same way. The technical capability (generating text, analyzing data, creating content) serves the larger mission of discipleship. But like the disciples, we need to learn where to cast the net.

At Bible Gateway, we’re seeing this play out with 23 million monthly users across 200+ translations. The users who get the most value aren’t necessarily the most technically sophisticated — they’re the ones who understand how to frame their spiritual questions in ways that digital tools can support.

A user searching “hope Bible verses” gets generic results. A user searching “Bible verses about hope after job loss, specifically for someone who feels God has abandoned them” gets targeted, actionable content that can actually help with discipleship.

The difference isn’t in the search technology, it’s in learning to ask better questions.

The Jesus Method of AI Prompting

Jesus’s interaction with the disciples gives us a framework for effective AI engagement:

Start with diagnosis. “Haven’t you any fish?” establishes the current state. Before jumping into solutions, AI needs to understand what you’re actually trying to accomplish. Not just the task, but the context around it.

Provide specific direction. “Throw your net on the right side” isn’t vague inspiration. It’s actionable guidance based on understanding the full situation. Good AI prompts are similarly specific about desired output, tone, length, audience, and constraints.

Trust the process. The disciples could have argued about which side of the boat was better. Instead, they followed the instruction. AI works best when you iterate based on results, not when you debate the approach.

Recognize the bigger picture. This wasn’t really about fishing, it was about discipleship. Using AI like this isn’t really about efficiency, it’s about enabling better ministry, better products, better service to people who need what you’re building.

Practical Applications for Ministry and Product

This principle scales across everything I work on. Whether it’s helping pastors with AI sermon preparation or building features for Bible Gateway’s global user base, the pattern holds: better questions lead to better outcomes.

For pastors: Instead of asking AI to “help with Bible study preparation,” try: “I’m teaching a small group of new believers, mostly in their 20s and 30s, about spiritual disciplines. They’re interested but overwhelmed by traditional approaches. Help me design a 4-week study on prayer that feels accessible and practical, with weekly exercises they can actually complete.”

For product teams: Instead of asking AI to “analyze user feedback,” try: “Review these 200 support tickets from the past month. Our mobile app’s Bible reading plans have a 40% completion rate, but we don’t know why people drop off. Identify patterns in user complaints that might indicate specific friction points in the first two weeks of plan usage.”

The difference is specificity informed by context, which is exactly what Jesus provided the disciples.

Why the Right Side of the Boat Matters

The disciples caught so many fish they couldn’t haul the net in. Not because the fish suddenly appeared, but because they were fishing where the fish actually were.

In the wisdom tradition, this is about alignment and understanding how things actually work rather than how we think they should work. AI isn’t magic, but it is powerful when applied with wisdom and clear direction.

The abundance wasn’t in the tool (the net) or even the technique (the casting). It was in the guidance that led them to the right place at the right time with the right approach.

For those of us building digital discipleship tools, this matters enormously. We’re not just solving technical problems, we’re helping people encounter God through technology. The quality of that encounter often depends on learning to ask better questions.

Sermon Illustration

The disciples had been fishing all night with empty nets. They knew how to fish — they were professionals. But when Jesus asked if they had caught anything and told them to throw their net on the right side of the boat, everything changed. Suddenly they caught so many fish they couldn’t pull the net in.

Sometimes our prayers feel like those empty nets. We’re asking God for help, but we’re not seeing results. Maybe the issue isn’t God’s willingness to provide, maybe it’s learning to ask better questions. Instead of “God, help me,” try “God, help me understand what You want me to learn through this situation.” Instead of “God, fix this,” try “God, show me how to respond faithfully right here.” The abundance might not be in getting what we think we want, but in learning to ask for what we actually need. And like the disciples, we might discover that the breakthrough was there all along, we just needed better direction about where to cast our nets.

Photo by Ankit Manoharan on Unsplash

Posted on

The Tower of Babel Was a Technology Problem, Not a Language Problem

Most pastors I’ve talked to use the Tower of Babel the same way. It’s a warning against ambition. Don’t reach too high. Stay in your lane.

That reading has legs. But I’ve spent the last several years building products for churches — first at SermonCentral, where we managed over 245,000 sermon manuscripts for 14,700+ subscribers, and now at Bible Gateway, which serves 23 million monthly visitors across 200+ Bible translations. When I read Genesis 11 through a product lens, I see something the ambition reading misses.

God didn’t judge the bricks.

“Come, let us build ourselves a city, with a tower that reaches to the heavens, so that we may make a name for ourselves.” — Genesis 11:4, NIV

The materials were fine. The engineering was fine. The goal — consolidating human fame — was the problem. And that distinction matters right now, because the church is having the wrong argument about AI.

AI Is Bricks and Mortar

The debate I keep hearing splits along predictable lines. One camp says AI threatens authentic ministry. The other says it’s the future of outreach. Both are fixated on the tool and ignoring the purpose behind it.

AI is a building material. Your spam filter runs on it. Your search results are shaped by it. Your congregation interacts with machine learning dozens of times a day without a second thought. The question of whether the church uses AI was settled years ago.

The question that matters: what are you building, and for whom?

A church that uses AI to transcribe sermons so a deaf congregant can read along on Monday morning — that’s building for the Kingdom. A church that uses AI-generated sermons so the pastor can spend less time in the text — that’s a tower with its own name on it.

Same bricks. The blueprint is what changed.

Augustine’s Framework (From 397 AD)

About 1,600 years before anyone worried about ChatGPT, Augustine drew a line I think about constantly in product work.

In De Doctrina Christiana (Book I, chapters 3-4), Augustine distinguished between two postures toward the things of this world: uti (to use) and frui (to enjoy as an end in itself). His argument: the things of creation are meant to be used as means toward loving God and neighbor. They become disordered when we treat them as destinations — when we frui the tool instead of the purpose the tool serves.

I’ve found this more useful than any AI ethics whitepaper.

Consider: a church uses AI to automate its weekly bulletin, freeing up a volunteer to spend those 3 hours visiting a homebound member. That’s uti. The tool serves a human end.

Now consider: a church uses AI to eliminate pastoral presence altogether. Their new chatbot handles prayer requests, the algorithm personalizes a sermon playlist, the system runs without a shepherd. That’s frui. The church has started delighting in efficiency as its own reward.

The technology didn’t change. The orientation did.

Three Questions Before Adopting Any AI Tool

I’ve spent enough time in product leadership to know that the best safeguard isn’t a policy document (I’ve written plenty of those — they collect dust). It’s a habit of asking the right questions before you build.

1. Who benefits?

If the honest answer is “the budget” and not “the congregation,” pause. Cost savings aren’t wrong — stewardship matters. But if the primary beneficiary is the institution rather than the people it serves, you’re building in the wrong direction. The best AI implementations I’ve seen at Bible Gateway started with a specific human need, not a line item.

2. What human activity does this replace, and should that activity stay human?

Administrative tasks — scheduling, data entry, email sorting, transcript formatting — automate freely. These are good uses of AI. They free up people for work that only people can do.

But pastoral care, spiritual formation, the ministry of presence — these resist automation for a reason. A hospital visit from a pastor matters because a person chose to show up. An AI can generate a thoughtful prayer. It cannot bear witness to suffering.

(This is the question I find hardest to answer cleanly, by the way. The line between “administrative” and “pastoral” blurs more than we’d like. Where does sermon research end and sermon preparation begin? I don’t have a tidy answer. I think the honest move is to keep asking.)

3. Does this build the church’s capacity or create dependency on a vendor?

This is the product leader in me talking. I’ve watched organizations — churches included — adopt tools that felt like empowerment but functioned as dependency. If your church can’t operate without a specific AI platform, you haven’t adopted a tool. You’ve adopted a landlord.

Look for AI that trains your people. Look for solutions where the value stays with the church if the vendor disappears tomorrow.

From Babel to Pentecost

The Bible doesn’t end the language story at Babel. It picks it back up in Acts 2.

“All of them were filled with the Holy Spirit and began to speak in other tongues as the Spirit enabled them. Now there were staying in Jerusalem God-fearing Jews from every nation under heaven. When they heard this sound, a crowd came together in bewilderment, because each one heard their own language being spoken.” — Acts 2:4-6, NIV

At Babel, human technology consolidated power and built a monument to self. God scattered and confused. At Pentecost, the Spirit moved — and people from every nation heard the gospel in their own mother tongue. Each person’s language, met where they were.

According to recent Barna research, 77% of pastors believe AI can have a positive impact. I think that’s right — but only if we’re asking the Babel question each time we adopt something new.

Here’s what that looks like in practice: a small church in rural Guatemala using AI translation to access theological training that was previously locked behind an English-language paywall. That points toward Pentecost.

A megachurch using AI to scale content production so it can dominate more digital market share. That points back toward Babel.

What We Build Next

I don’t think the church needs to fear AI. I also don’t think it needs to be infatuated with it (and having built products in this space since 2018, I’ve watched both reactions play out in real time).

The bricks and mortar are here. They’re powerful. They’re going to keep getting more powerful. The church’s job is to ask the Babel question every time: what are we building, and whose name is on it?

That question doesn’t have a permanent answer. It has to be asked again with every new tool, every new capability, every new vendor pitch. And I think the churches that will get this right are the ones willing to sit with the discomfort of asking it honestly — even when the answer means building slower.

Sermon Illustration: The Tower of Babel and AI

When the people of Babel built their tower, God didn’t judge the bricks. He didn’t condemn the mortar or the engineering. The materials were fine. The problem was the purpose: “let us make a name for ourselves” (Genesis 11:4, NIV).

Today, AI is the new brick and mortar. Churches face the same question Babel faced: what are we building, and for whom? AI that frees a pastor to sit at a hospital bedside — that’s technology in service of presence. AI that replaces the pastor at the bedside — that’s a tower with our own name on it.

But the story doesn’t end at Babel. At Pentecost, God took language itself — the very thing He confused at Babel — and used it to carry the gospel across every barrier (Acts 2:4-6). The bricks are in our hands. The blueprint is the question.

Posted on

25 Skills Every Product Manager Should Be Building in 2026

Product Manager sitting in his home office reading

There’s no shortage of “skills for PMs” lists on the internet. Most of them read like a job description, technically correct, but practically useless.

This isn’t that list. These are the 25 skills I’ve seen separate the product managers who move the needle from the ones who stay busy. I’ve organized them by the areas where I see the biggest gaps, not by some theoretical framework. Some of these are timeless. Some are specific to right now. All of them are things I wish someone had told me earlier in my career.

I. Customer Obsession

These are the skills that everything else builds on. Get these wrong and nothing else matters.

1. Deep Customer Knowledge

You can’t fake this one. The best PMs I’ve worked with can describe their top customer segments in vivid detail – not just demographics, but the actual daily workflow, the frustrations, the workarounds they’ve built, the language they use when they’re annoyed.

This doesn’t come from dashboards. It comes from sitting with customers, watching them use your product, and resisting the urge to defend your design choices when they struggle. Do this monthly, not quarterly. The PMs who “don’t have time” for customer conversations are the same ones who build features nobody uses.

2. Jobs-to-be-Done Thinking

Clayton Christensen’s framework has become so mainstream that people name-drop it without actually applying it. The real skill isn’t knowing what JTBD is, it’s being able to articulate the job your customer is hiring your product to do in one sentence.

If you can’t do that, you don’t understand your customer well enough yet. Every feature decision should trace back to that job. If it doesn’t advance the job, it’s noise.

3. Continuous Discovery

Teresa Torres literally wrote the book on this. The skill isn’t “doing user research” – it’s building a rhythm of weekly customer touchpoints that inform your decisions in real-time, not once a quarter when the research team delivers a 40-page report nobody reads.

The PMs who do this well talk to 2-3 customers every single week. Not formal research sessions with screeners and discussion guides. Quick, focused conversations that answer specific questions about specific opportunities.

I have “virtual coffee” times available on my calendar and invite users on our emails to book some time with me. It’s fantastic and gives me tons of insight into our customers.

4. Knowing When to Ignore Feedback

This sounds counterintuitive after three skills about listening to customers. But one of the hardest skills in product management is knowing WHICH feedback to act on and which to file away.

Not every customer request is a product insight. Sometimes a customer wants something that serves them but hurts the broader user base. Sometimes they’re describing a symptom, not the root cause. The skill is triangulating. When you hear the same pain from multiple segments, supported by data, that’s signal. When one loud customer demands something, that’s noise.

5. Empathy That Goes Beyond Platitudes

Every PM claims to have empathy. The actual skill is translating empathy into product decisions. It’s the difference between saying “I understand the user’s frustration” and redesigning the onboarding flow because you watched someone struggle for 8 minutes trying to complete a task that should take 30 seconds.

Real empathy is uncomfortable. It means watching your product fail in real-time and sitting with that feeling instead of explaining it away.

II. Strategic Thinking

These are the skills that determine whether your team is building the right things.

6. Product Vision

A compelling product vision describes what the world looks like 2-5 years from now if your product succeeds. Not a feature list. Not a technology roadmap. A picture of a better future for your customer.

The skill is making this concrete enough to inspire and vague enough to allow room for discovery. “We’ll be the leading platform for X” is not a vision. “Every pastor will have a personal AI-powered sermon preparation assistant that cuts their weekly prep time in half” – that’s a vision.

7. Product Strategy

I wrote about the 10 most common strategy mistakes recently, and the biggest one is teams that have no strategy at all — just a backlog they call a strategy.

The skill here is making choices. Real ones. Strategy means explicitly deciding what you will NOT do, who you will NOT serve, and which opportunities you will walk away from. If your strategy doesn’t make someone uncomfortable, it’s not a strategy.

8. Ruthless Prioritization

This is the skill that separates senior PMs from everyone else. You will always have more opportunities than capacity. The question is never “should we build this?” Everything on your list is probably worth building. The question is “should we build this INSTEAD of that?”

Frameworks like RICE scoring help, but the real skill is having the conviction to say no to good ideas because they’re not the BEST idea right now. Warren Buffett’s two-list strategy applies: identify your top 25 priorities, circle the top 5, and treat the other 20 as your “avoid at all costs” list.

9. Outcome-Focused Roadmapping

The shift from output-based roadmaps (“Q2: Ship feature X, Y, Z”) to outcome-based roadmaps (“Q2: Reduce trial-to-paid time from 14 days to 7 days”) is one of the most important evolutions in modern product management.

The skill is framing your roadmap around the problems you’re solving and the metrics you’re moving, not the features you’re building. This gives your team room to discover the best solution instead of being locked into a predetermined one.

10. Saying No (and Making It Stick)

Every PM knows they should say no more often. The actual skill is saying no in a way that maintains relationships and builds trust. “No, because our strategy is focused on X, and here’s why that matters more right now” is dramatically different from just “no.”

The best PMs I’ve seen turn a “no” into a learning moment by explaining the reasoning, sharing the data, and making the person feel heard even when the answer isn’t what they wanted. I’ve found that people can disagree with a well-reasoned decision. What often causes stress is ambiguity.

III. Execution and Delivery

These are the skills that turn strategy into a shipped product.

11. Rapid Experimentation

The ability to test ideas in hours or days instead of weeks or months is a superpower. This means prototyping. Not pixel-perfect mockups, but rough, testable concepts that answer specific questions.

Can users find this feature? Does this flow make sense? Will anyone actually use this? You can answer all of these questions with a prototype and 5 users in a single afternoon.

12. Writing Clear Requirements

This is an underrated skill. The gap between “what the PM imagined” and “what engineering built” is almost always a requirements problem, not a competence problem.

The skill is writing requirements that are specific enough to build from but flexible enough to allow engineering creativity. I’ve found that focusing on the PROBLEM and the SUCCESS CRITERIA while leaving the implementation approach to engineering produces the best results.

13. Data Literacy

You don’t need to be a data scientist, but you need to be dangerous with data. That means understanding statistical significance (so you don’t kill an A/B test too early), knowing which metrics actually matter for your product, and being able to query your own data when the analytics team is backed up.

AI has made this dramatically easier. You can now describe what you want in plain English and get a SQL query back. That’s a genuine unlock for PMs who previously had to wait days for a data pull.

14. Delivery Management

Understanding how your team ships code, whether it’s sprint cycles, deployment pipelines, feature flags, rollback procedures, makes you a better PM. Not because you need to manage the process (that’s engineering’s job), but because understanding the constraints helps you make better tradeoff decisions.

“Can we ship this behind a feature flag to 10% of users first?” is a much better question than “when will this be done?”

15. Technical Literacy

You don’t need to code, but you need to understand enough about your technology stack to have meaningful conversations with engineering. What’s an API? What are the database constraints? Why does this “simple” change actually require refactoring three services?

The skill is asking good technical questions, not having the answers. When your engineering lead says “that’s a 3-month project,” you should be able to ask “what makes it 3 months?” and understand the answer.

IV. Communication and Influence

These are the skills that get people aligned and keep them there.

16. Stakeholder Management

Your stakeholders have competing priorities, different incentive structures, and varying levels of product literacy. The skill is navigating all of that without losing your strategic direction.

The best approach I’ve found: radical transparency about your decision-making process. Share the data, explain the tradeoffs, make a clear recommendation, and invite disagreement before the decision, not after. People support what they help create, even if they don’t get everything they wanted.

17. Executive Communication

Executives don’t want details. They want: what’s the problem, what’s the recommendation, and what do you need from them. That’s it.

The skill is compression, taking a complex product situation and distilling it into a 2-minute narrative that leads to a clear ask. If you can’t explain your strategy in the time it takes to ride an elevator, you haven’t thought about it clearly enough.

18. Cross-Functional Leadership

PMs lead without authority. You can’t tell engineering what to build, design what to design, or marketing what to say. You can only influence.

The skill is making other teams WANT to follow your lead because you’ve earned their trust. That means understanding their constraints, respecting their expertise, giving them credit publicly, and never throwing them under the bus when something goes wrong.

19. Writing as a Leadership Tool

Product managers who write well have an outsized advantage. Strategy docs, product briefs, stakeholder updates, customer communications – writing is how PMs scale their influence beyond the meetings they attend.

Jeff Bezos banned PowerPoint at Amazon for a reason. Clear writing forces clear thinking. If you can’t write a coherent one-page strategy doc, your strategy probably isn’t coherent.

20. Storytelling with Data

Data alone doesn’t persuade anyone. The skill is wrapping data in a narrative that makes people care. “Churn increased 3%” is a data point. “We’re losing 40 paying customers every month, and here’s what they’re telling us on the way out the door” is a story that drives action.

Every dashboard metric should have a “so what?” attached to it. If you can’t articulate the “so what,” the metric isn’t useful yet.

V. Personal Mastery

These are the skills that compound over time and separate the good from the great.

21. AI Fluency

This is the new table-stakes skill for 2026. Not building AI products (though that’s increasingly common) but using AI tools to accelerate your own work.

I like Dell computers tagline of: “It’s a you-multiplier.”

Customer research synthesis, competitive analysis, PRD drafting, experiment design, data analysis, all of these are dramatically faster with AI assistance. PMs who aren’t using AI in their daily workflow are leaving massive productivity on the table.

The skill isn’t prompting. It’s knowing which parts of your work benefit from AI acceleration and which parts still require human judgment. Strategy, customer relationships, and cross-functional trust can’t be automated. Research synthesis, first-draft writing, and data analysis absolutely can.

22. Product Evangelism

Your product needs a champion, and that’s you. The skill is inspiring genuine excitement in your team, your stakeholders, and your customers without crossing the line into hype.

The best product evangelists I’ve seen lead with the customer problem, not the product solution. “Let me tell you about a pastor who spent 12 hours preparing a single sermon because our tools weren’t good enough” hits harder than “let me show you our new feature.”

23. Managing Your Energy, Not Just Your Time

PM burnout is real. The role pulls you in every direction: stakeholder meetings, customer calls, sprint planning, strategy reviews, fire drills. You can optimize your calendar perfectly and still burn out.

The skill is recognizing which activities give you energy and which drain it, then structuring your week accordingly. For me, customer conversations and strategy work are energizing. Back-to-back status meetings are draining. I protect my calendar accordingly.

24. Continuous Learning

The product management discipline is evolving rapidly. The frameworks that worked 3 years ago might not work today. The best PMs read broadly, attend selectively, and most importantly apply what they learn immediately.

Books that have shaped my thinking: Inspired by Marty Cagan, Continuous Discovery Habits by Teresa Torres, The Lean Startup by Eric Ries, Escaping the Build Trap by Melissa Perri, and Chief Customer Officer 2.0 by Jeanne Bliss. But reading without applying is just entertainment.

25. Intellectual Humility

This might be the most important skill on the entire list. The willingness to say “I was wrong” or “I don’t know” is what separates PMs who keep growing from ones who plateau.

Every strong opinion you hold about your product, your customers, or your market should come with an asterisk: “based on what I know right now.” New data should change your mind. Customer feedback that contradicts your hypothesis should make you curious, not defensive.

The best product managers I’ve worked with hold their strategies with conviction AND their assumptions with humility. That balance is the whole game.

The Thread That Connects All 25

If I had to distill all of these into a single principle, it would be this: the best product managers are relentlessly curious about their customers and brutally honest about what they don’t know.

Every skill on this list is either about understanding customers more deeply or making better decisions with incomplete information. That’s the job. Everything else is just technique.

The good news? Every one of these skills is learnable. None of them require a specific degree, a specific title, or a specific number of years in the role. They require intentional practice and the willingness to be uncomfortable while you’re learning.

Start with the ones where you have the biggest gap. Work on them deliberately. And be patient with yourself. The best PMs I know are still working on all 25.

Frequently Asked Questions

What is the most important skill for a product manager?

Deep customer knowledge is the foundational skill that enables everything else. Without a genuine understanding of your customers, their workflows, pain points, and goals, no amount of strategic thinking, technical literacy, or stakeholder management will produce great products. Build a habit of weekly customer conversations and the other skills become dramatically more effective.

How do product managers use AI in 2026?

Product managers use AI primarily for research acceleration like synthesizing customer interviews, generating competitive intelligence, drafting PRDs and experiment hypotheses, and querying data with natural language. The key skill is knowing which tasks benefit from AI assistance (research, analysis, first drafts) and which still require human judgment (strategy decisions, customer relationships, cross-functional trust-building).

What technical skills do product managers need?

Product managers don’t need to code, but they need enough technical literacy to have meaningful conversations with engineering. This includes understanding APIs, database constraints, deployment processes, and architectural tradeoffs. The goal isn’t to make technical decisions, it’s to ask informed questions and understand the implications of technical choices on product capabilities and timelines.

How do you transition into product management?

The most common entry points are from engineering, design, data analytics, or customer-facing roles like support or sales. Each background brings a natural strength: engineers bring technical depth, designers bring user empathy, analysts bring data fluency, and customer-facing roles bring direct insight into user pain points. Focus on building the skills in whichever category you’re weakest. Most transitions fail not because of lack of domain knowledge, but because of gaps in communication, strategic thinking, or customer understanding.

Posted on

15 quotes to stir Courageous Leadership

I’ve been collecting quotes on courageous leadership for a while now. The kind that don’t just sound good on a poster but actually rearrange how you think about showing up for the people in front of you.

Here’s the question that started this collection:

Can an individual affect their society by simply, courageously caring for the individual in front of them enough to see who they truly are and encourage them into that identity?

I believe the answer is yes. And these 15 quotes have shaped how I try to live that out.

On Seeing People

  1. How many of us are stuck in the daily grind of survival? If you were to plot yourself on Maslow’s Hierarchy of Needs, where would you be today? Most of us live at level 3, but David Whyte challenges us to step beyond, to risk being truly seen and to see others as they really are.

  2. “The greatest thing a human soul ever does in this world is to see something and tell what it saw in a plain way. Hundreds of people can talk for one who can think, but thousands can think for one who can see.” – John Ruskin

  3. “Attention is the rarest and purest form of generosity.” – Simone Weil. Constant distraction makes full presence rare. Choosing to be fully present with another person is an act of courage.

On Leading with Vulnerability

  1. “Vulnerability is not winning or losing; it’s having the courage to show up and be seen when we have no control over the outcome.” – Brene Brown. This applies to every hard conversation you’re avoiding right now.

  2. “The only thing more unthinkable than leaving was staying; the only thing more impossible than staying was leaving.” – Elizabeth Gilbert. Sometimes the most courageous leadership decision is the one that costs you the most personally.

  3. “Have I not commanded you? Be strong and courageous. Do not be afraid; do not be discouraged, for the Lord your God will be with you wherever you go.” – Joshua 1:9. Courage is the decision that something else matters more.

On Doing the Hard Thing

  1. “The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood.” – Theodore Roosevelt. Courageous leaders lead from inside the mess.

  2. “You gain strength, courage, and confidence by every experience in which you really stop to look fear in the face. You must do the thing which you think you cannot do.” – Eleanor Roosevelt

  3. “Courage is not the absence of fear, but rather the judgment that something else is more important than fear.” – Ambrose Redmoon. I come back to this one regularly. Especially when I’m about to say something in a meeting that I know won’t be popular but needs to be said.

On Serving Others

  1. “Everybody can be great because anybody can serve. You don’t have to have a college degree to serve. You don’t have to make your subject and verb agree to serve. You only need a heart full of grace and a soul generated by love.” – Martin Luther King Jr.

  2. “The best way to find yourself is to lose yourself in the service of others.” – Mahatma Gandhi. The leaders who’ve had the deepest impact on my life were the ones who showed up for me when it cost them something.

  3. “Do nothing out of selfish ambition or vain conceit. Rather, in humility value others above yourselves.” – Philippians 2:3. This is the hardest standard of leadership I know. And the most transformative when you actually live it.

On Persistence

  1. “Success is not final, failure is not fatal: it is the courage to continue that counts.” – Winston Churchill

  2. “Courage doesn’t always roar. Sometimes courage is the quiet voice at the end of the day saying, ‘I will try again tomorrow.’” – Mary Anne Radmacher. This one resonates with anyone who’s had a week where nothing went right but showed up on Monday anyway.

  3. “Let us not become weary in doing good, for at the proper time we will reap a harvest if we do not give up.” – Galatians 6:9. The most courageous thing you might do today is simply not quit.

The Thread

Courageous leadership is the daily decision to see people, serve them, and keep going when it would be easier to stop.

That’s available to anyone, in any role, at any level. You don’t need a title to lead courageously. You just need to care enough about the person in front of you to show up fully. And then do it again tomorrow.

Posted on

25 Skills a Product Manager should focus on in 2025

I’ve been in product leadership long before the term ‘Product Management’ became a common buzzword. Over the past eight years, I’ve held various titles with ‘Product’ in them, and yet, every day brings new lessons and insights. As I approach 2025, I’ve realized the importance of grounding myself in the principles that have guided me so far. This list serves as a personal reminder—a collection of foundations I’ve built upon, shaped by insights from books like Crucial Conversations, INSPIRED, The E-Myth Revisited, and The Mom Test.

I. Foundational Principles

  1. Embrace the Product Mindset: Product management is not just a job; it’s a mindset 1. It requires a passion for solving customer problems and a commitment to continuous improvement.
  2. Deep Customer Knowledge: Become an undisputed expert on your customers2. This involves understanding their needs, pain points, and desires through both qualitative and quantitative data3.
  3. Data-Driven Decisions: Be comfortable with data and analytics4. Use data to understand how customers are using your products, analyze A/B test results, and inform product decisions.
  4. Master the Product: Be an expert on your actual product and your industry. Share your knowledge openly and generously.
  5. Continuous Learning: Stay intellectually curious and quickly apply new technologies to solve problems for customers5.

II. Team Dynamics & Collaboration

  1. Build Strong Product Teams: Focus on building and nurturing strong, collaborative relationships with your product team. A product team typically includes a product manager, a product designer, and engineers.
  2. Empowered Teams: Champion empowered product teams that are equipped to solve business problems. Ensure your team understands the company vision and how their work contributes to the larger purpose6.
  3. Cross-Functional Collaboration: Work effectively with product designers, engineers, and product marketing managers. Ensure product marketing is embedded with the product team7.
  4. Effective Communication: Communicate product learnings clearly and consistently. Keep stakeholders informed and engaged8.
  5. Delivery Management: Recognize the importance of delivery managers in removing obstacles for the team. Their work ensures that the team can focus on building valuable products9.

III. Strategic Product Development

  1. Product Vision: Develop a compelling and inspiring product vision10. Use it to articulate your purpose and inspire the team11.
  2. Product Strategy: Define a clear product strategy that serves as a path to achieving the product vision. Ensure alignment between the product strategy and overall business strategy12.
  3. Product Principles: Complement your product vision and strategy with a set of guiding principles that define the nature of the products you want to create13.
  4. Outcome-Focused Roadmaps: Shift from output-based roadmaps to those focused on business outcomes14. Ensure every roadmap item is tied to a specific business objective.
  5. Embrace Discovery: Prioritize product discovery, which involves collaboration between product management, UX design, and engineering. Tackle risks before writing any code.
  6. Prioritize Ruthlessly: Focus on a single, scalable idea rather than jumping on every good one15.
  7. Problem-First Approach: Focus on solving the underlying problem. Don’t get caught up in the solution before you’ve fully understood the problem16.
  8. Customer Discovery Programs: Use customer discovery programs to ensure that you’re building a product that customers love.

IV. Product Discovery and Delivery

  1. Master Discovery Techniques: Utilize various discovery techniques to understand customer needs and validate ideas. This includes opportunity assessment, customer letters, and startup canvases.
  2. Rapid Experimentation: Use prototypes to conduct rapid experiments17. Test ideas with users, customers, engineers, and business stakeholders in hours and days, not weeks and months18.
  3. Usability Testing: Conduct regular usability tests to identify friction points in prototypes. Use these tests to learn about how customers use your products19.
  4. Continuous Delivery: Strive for frequent release cycles to ensure teams move quickly and release with confidence.
  5. Iterative Approach: Understand that it typically takes several iterations to get the execution of an idea to the point where it delivers the expected business value20.

V. Leadership & Growth

  1. Product Evangelism: Become an effective evangelist for your product. Inspire your team, stakeholders, and customers by “selling the dream”. Use prototypes to communicate the product vision21.
  2. Adaptability: Be prepared to adapt to changes in the market and new trends22. Be flexible with the details, but remain stubborn on the overall vision.

Conclusion

Product management in 2025 will demand a combination of deep technical knowledge, strategic thinking, and a genuine passion for solving customer problems. By focusing on these 25 areas, product managers can position themselves for success and contribute to the creation of truly impactful products. It’s not about having all the answers, but about asking the right questions and embracing a continuous learning mindset.

  1. “The art of Product Management is the art of life itself. Surround your-selves by great people, focus on your mojo, build great stuff with integrity, hold strong opinions but lightly. And Marty is one of the best teachers of this art.” —Punit Soni, Founder and CEO, Robin, Former Google APM ↩︎
  2. “you need to become an acknowledged expert on the customer: their issues, pains, desires, how they think—and for business products, how they work, and how they decide to buy.” —INSPIRED, Marty Cagan ↩︎
  3. “Without this deep customer knowledge, you’re just guessing. This requires both qualitative learning (to understand why our users and customers behave the way they do), and quantitative learning (to understand what they are doing)” —INSPIRED, Marty Cagan ↩︎
  4. “… product managers are expected to be comfortable with data and analytics. They are expected to have both quantitative skills as well as qualitative skills. The Internet enables unprecedented volume and timeliness of data.
    A big part of knowing your customer is understanding what they’re doing with your product. Most product managers start their day with half an hour or so in the analytics tools, understanding what’s been happening in the past 24 hours. They’re looking at sales analytics and usage analytics. They’re looking at the results of A/B tests.” —INSPIRED, Marty Cagan ↩︎
  5. Be “intellec-tually curious, quickly learning and applying new technologies to solve problems for customers, to reach new audiences, or to enable new business models.” —INSPIRED, Marty Cagan ↩︎
  6. “The product teams need to have the necessary business context. They need to have a solid understanding of where the company is heading, and they need to know how their particular team is supposed to contribute to the larger purpose.” —INSPIRED, Marty Cagan ↩︎
  7. “… because that’s where they are connected to the experience that the customer is having an opportunity to engage with.” —INSPIRED, Martina Lauchengco ↩︎
  8. “Evangelize continuously and relentlessly. There is no such thing as over-communicating when it comes to explaining and selling the vision. Especially in larger organizations, there is sim-ply no escaping the need for near-constant evangelization. You’ll find that people in all corners of the company will at random times get nervous or scared about something they see or hear. Quickly reassure them before their fear infects others.” —INSPIRED, Marty Cagan ↩︎
  9. “In growth-stage and enterprise companies, many product managers complain that they have to spend far too much of their time doing project management activities. As a result, they have almost no time to address their primary product responsibility: ensuring that the engineers have a product worth building.
    Delivery managers are a special type of project manager whose mission is all about removing obstacles—also known as impediments—for the team. Sometimes, these obstacles involve other product teams, and sometimes they involve non-product functions. In a single day, they might track down someone in marketing and press them for a decision or an approval, coordinate with the delivery manager on another team about prioritizing a key dependency, persuade a product designer to create some visual assets for one of the front-end developers, and deal with a dozen other similar roadblocks.” —INSPIRED, Marty Cagan ↩︎
  10. “The product vision describes the future we are trying to create, typically somewhere between two and five years out. For hardware or device-centric companies, it’s usually five to 10 years out.
    Note that this is not the same as the company mission statement. Examples of mission statements are “organize the world’s information” or “make the world more open and connected” or “enable anyone any-where to buy anything anytime.” Mission statements are useful, but they don’t say anything about how we plan on accomplishing that. That’s what the product vision is for.” —INSPIRED, Marty Cagan ↩︎
  11. “Start with why. This is coincidentally the name of a great book on the value of product vision by Simon Sinek. The central notion here is to use the product vision to articulate your purpose. Everything follows from that.
    Fall in love with the problem, not with the solution. I hope you’ve heard this before, as it’s been said many times, in many ways, by many people. But it’s very true and something a great many product people struggle with.” —INSPIRED, Marty Cagan ↩︎
  12. “Communicate the strategy across the organization. This is part of evangelizing the vision. It’s important that all key business partners in the company know the customers we’re focused on now and which are planned for later. Stay especially closely synced with sales, marketing, finance, and service.” —INSPIRED, Marty Cagan ↩︎
  13. “Where the product vision describes the future you want to create, and the product strategy describes your path to achieving that vision, the product principles speak to the nature of the products you want to create.” —INSPIRED, Marty Cagan ↩︎
  14. … focus “on outcome and not output. Realize that typical product roadmaps are all about output. Yet, good teams are asked to deliver business results.
    Most of the product world has the same definition for product roadmap, but there are a few variations. I define product roadmap as a prioritized list of features and projects your team has been asked to work on. These product roadmaps are usually done on a quarterly basis, but sometimes they are a rolling three months, and some companies do annual roadmaps.” —INSPIRED, Marty Cagan ↩︎
  15. “Startups are about focusing and executing on a single, scalable idea rather than jumping on every good one which crosses your desk.” —The Mom Test, Rob Fitzpatrick ↩︎
  16. “This is another reason why typical product roadmaps are so problematic. They’re lists of features and projects where each feature or project is a possible solution. Somebody believes that feature will solve the problem or it wouldn’t be on the roadmap, but it’s all too possible they are wrong. It’s not their fault—there’s just no way to know at the stage it’s put on the roadmap.
    However, there very likely is a legitimate problem behind that potential solution, and it’s our job in the product organization to tease out the underlying problem and ensure that whatever solution we deliver solves that underlying problem.” —INSPIRED, Marty Cagan ↩︎
  17. “… use prototypes to conduct rapid experiments in product discovery, and then in delivery, we build and release products in hopes of achieving product/market fit, which is a key step on the way to delivering on the company’s product vision.” —INSPIRED, Marty Cagan ↩︎
  18. “If we can prototype and test ideas with users, customers, engi-neers, and business stakeholders in hours and days—rather than in weeks and months—it changes the dynamics, and most important, the results.
    It’s worth pointing out that it isn’t the list of ideas on the roadmap that’s the problem. If it was just ideas, there’s not much harm in that. The issue is that anytime you put a list of ideas on a document entitled “roadmap,” no matter how many disclaimers you put on it, people across the company will interpret the items as a commitment. And that’s the crux of the problem, because now you’re committed to build-ing and delivering this thing, even when it doesn’t solve the underlying problem.” —INSPIRED, Marty Cagan ↩︎
  19. “You will need to define in advance the set of tasks that you want to test. Usually, these are fairly obvious. If, for example, you’re building an alarm clock app for a mobile device, your users will need to do things like set an alarm, find and hit the snooze button, and so on. There may also be more obscure tasks, but concentrate on the primary tasks—the ones that users will do most of the time.
    Some people still believe that the product manager and the prod-uct designer are too close to the product to do this type of testing objectively, and they may either get their feelings hurt or only hear what they want to hear. We get past this obstacle in two ways. First, we train the product managers and designers on how to conduct themselves, and second, we make sure the test happens quickly—before they fall in love with their own ideas. Good prod-uct managers know they will get the product wrong initially and that nobody gets it right the first time. They know that learning from these tests is the fastest path to a successful product.” —INSPIRED, Marty Cagan ↩︎
  20. “…even with the ideas that do prove to be valuable, usable, feasible, and viable, it typically takes several itera-tions to get the execution of this idea to the point where it delivers the expected business value that management was hoping for. This is often referred to as time to money” —INSPIRED, Marty Cagan  ↩︎
  21. “The product vision needs to inspire. Remember that we need product teams of missionaries, not mercenaries. More than anything else, it is the product vision that will inspire missionary-like passion in the organization. Create something you can get excited about. You can make any product vision meaningful if you focus on how you genuinely help your users and customers.” —INSPIRED, Marty Cagan ↩︎
  22. “Determine and embrace relevant and meaningful trends. Too many companies ignore important trends for far too long. It is not very hard to identify the important trends. What’s hard is to help the organization understand how those trends can be leveraged by your products to solve customer problems in new and better ways.” —INSPIRED, Marty Cagan ↩︎
Posted on

Starting a consulting business

A close friend recently approached me asking for advice. They are considering launching a consulting business and in doing their research, they wanted to know any “off the cuff” words of wisdom I might have for them. Having run my own graphic design and website development firm for several years, I had some things to say.

When I was starting my company in the USA I had approached a businessman and asked a similar question, his wisdom was invaluable and I would say it is part of the reason my company was successful.

First, let’s define successful.

Each individual needs to define success in their own terms. For me personally, success would look far different today than it did a decade ago. I’m going to assume you’re reading this because you’re defining success monetarily, so let’s move on.

Look around enough and you will begin to recognize the “blah blah me too lemming-like” marketing speak everywhere. It’s boring and useless and begins to look pathetic. Be bold enough to plant a flag on ONE specific mountain and work hard to be the unquestionable SME (subject matter expert) to defend it. Find good people you can trust to hand off certain requests you are regularly getting asked for, maybe even work out a finders fee, but stand firm on top of your mountain. Get speaking gigs, get recognized, be the expert.

ADD VALUE. When you are an expert and you are adding value, you’ll be busy and well paid.

Consider these very distinct stages in how you make money in consulting, in order:

  1. Know your hourly rate and use it as a positioning tool.
  2. Get a second shift job to keep from compromising while you build it. 
  3. Fill >60% of ALL the time you work with residual fees. 
  4. Maintain >60% with an increasingly higher hourly rate. 
  5. Move exclusively to package pricing w/o reference to hours. 
  6. Build scalable income (webinars, books, etc.).

I personally have not made it to ‘6’ yet. I always am a bit nervous to put myself out there as I do not want to come across braggadocios.

Be very helpful in giving away terrific advice for free as long as you don’t personalize it; then charge ridiculous amounts of money to do so.

I spoke at an event once where I gave ALL of my secrets away. It was a wild plan, but it worked. I gained more business from that engagement than I could possibly handle and my hourly rate nearly doubled because of it. The reason: the business owners trusted me.

Figure out why you’re in business. I’d suggest these three things, in this order: 

  1. Make money. 
  2. Make a difference. 
  3. Enjoy the process.

If you don’t charge enough, no one listens and you don’t have an opportunity to make a difference. But just charging a lot of money, especially in a service-client relationship, can be soul crushing. You must find the win-win balance where you’re making enough money while feeling like your customers are winning. 

Take chances and be different. This leads me into my second take-away:

Be amazing at communicating. I have found transparency as highly valued in the C-Suite.

What I mean by transparency is: communicate as clearly and often as possible. Imagine yourself in the C-Suite and answer the questions you imagine them asking – especially the difficult ones. If your product is necessary then it will be easy to sell. Find out why it’s necessary and walk boldly as the expert in that category. In 2007 the iPhone was the answer – Apple wasn’t hiring salespeople to sell it, the product sold itself. 

Posted on

Self-Awareness and Leadership

I had to write a quick response today to the question:

Why do you believe a leader needs to be reasonably self-aware if they are going to be a good leader?

What do you think of my response:

When I envision a leader who is not self-aware, I think of an individual dealing with insecurity then attempting to hide it with pride and arrogance. There are several reasons a leader must be self-aware, but I will discuss the one most important to me: If you are unable to read what’s going on with yourself, how will you read your subordinates and lead them well? A leader with no self-awareness would end up making choices on whims versus logic and would demoralize everyone who works for them. Beyond having a high employee turn over rate, this type of leader would end up costing the organization money and time due to them working on ego boosting projects while avoiding rather than delegating other projects. They would not be capable of delegating due to their lack of personal skills as well as not being able to recognize the skills of their subordinates. 

Further Reading: