I switched from leading product at SermonCentral — 14,700 subscribers, two-week ship cycles — to a product serving 23 million users at a publisher founded in 1817. The contrast hit me on Day 3 when I wanted to update a single line of copy.
At SermonCentral, I’d open VS Code, push the change, and watch it go live. At my new role, that same change required stakeholder alignment across three departments, QA testing, and a deployment window I hadn’t even learned to schedule yet.
This is what the first 100 days of product leadership looks like inside a legacy institution — and it’s nothing like what I expected.
The Codebase Carries 20 Years of Decisions You Didn’t Make
When the first line of code for a product launches in 1993, you’re inheriting two decades of product decisions baked into the architecture. Database schemas that made perfect sense in 2004. API endpoints that were cutting-edge in 2010. Frontend frameworks that were the right choice when they were implemented — and still work fine, which is exactly why they haven’t been replaced.
At SermonCentral, when something felt clunky, I knew exactly why. I’d built it, or my co-founder had. Here, I was an archaeologist. Every feature had a story I didn’t know yet.
The temptation is to immediately start proposing rewrites. What I learned: listen first. The person who built that “outdated” search feature probably solved problems I hadn’t discovered yet. I spent my first 60 days in the codebase like I was studying someone else’s sermon notes — not to critique, but to understand the thinking behind each decision.
Stakeholder Alignment Takes 3x Longer (And That’s Actually Good)
At a startup, product decisions happen fast because the stakes are binary: ship something users love, or run out of money. At a product with 23 million users, the stakes are different. Break the wrong thing and you’re not just losing customers — you’re disrupting someone’s daily devotional time, interfering with a pastor’s sermon prep on Thursday night, affecting a small group leader in rural Kenya who depends on reliable access to Scripture.
A feature that would have been a 30-minute conversation at SermonCentral became a series of meetings involving product, engineering, content, legal, and partnership teams. Not because people were slow or bureaucratic — because the impact radius was massive.
Three months ago, I would have seen this as friction. Now I see it as risk management. The process is longer, but the decisions are better. I just had to recalibrate what “move fast” means when millions of people depend on you not breaking something they rely on spiritually.
Three Things That Surprised Me in the First 100 Days of Product Leadership
The depth of the data. The behavioral signals most startups dream about were already there. Not just what people read, but how they read it — chapter-by-chapter completion rates, cross-reference click patterns, search query analysis going back years across multiple Bible translations, languages, and device types. This wasn’t a Google Analytics dashboard. It was instrumented user behavior data that would make most SaaS companies jealous.
The team was already building what I thought we needed. I came in assuming I’d need to evangelize for modern product practices — user research, A/B testing, data-driven feature prioritization. Turns out, the team was already doing all of this. They just weren’t talking about it in Silicon Valley buzzwords. I thought I was joining a legacy institution that needed digital transformation. Instead, I found a digitally sophisticated team that needed someone to help coordinate and scale what they were already building.
The urgency is real. When people hear “200-year-old publisher,” they assume slow-moving and comfortable. That’s not what I found. Digital isn’t optional when you’re competing with products that have billions of installs. The urgency here is channeled through process, not around it. At a startup, urgency means cutting corners. Here, urgency means making the process faster and more effective.
What I’d Tell Any Product Leader Joining a Legacy Institution
Listen for 60 days. I thought I knew what the product needed after my first week. I was wrong about almost everything. The problems I identified weren’t actually problems — they were features working as intended for use cases I hadn’t discovered yet. Spend two months learning the system before you start trying to change it. Talk to everyone. Read the old product specs. Understand not just what the product does, but why it was built that way.
Ship something small by Day 90. Listening is important, but you also need to prove you can execute in their environment. Find something genuinely small — a bug fix, a copy improvement, a minor UX enhancement — and ship it. My first shipped feature was a tiny improvement to a comparison tool. It took three weeks to get live (compared to three hours at SermonCentral), but I learned more about the system from that one change than from a month of meetings.
Earn trust before proposing transformation. Legacy institutions have heard transformation pitches before — many from consultants who didn’t stick around to see the results. Your credibility comes from understanding what’s already working and why. The most effective change agents I’ve seen inside legacy organizations aren’t the ones who come in with dramatic transformation roadmaps. They’re the ones who make the existing system work better, then gradually expand the definition of “better” over time.
The Long Game
Building inside legacy institutions means accepting that transformation happens in years, not quarters. Your first job is to understand what’s already working before you start changing what isn’t. This is true whether you’re joining a publisher, a denomination, a hospital system, or any organization built to outlast its founders.
But it also means you’re building on a foundation tested by millions of users over decades. When you do ship something new, it immediately inherits that scale and stability. That’s a trade-off I didn’t expect to appreciate — but four months in, I do.
The question isn’t whether legacy organizations can innovate. The question is whether product leaders can learn to innovate within systems designed to last longer than most startups exist. From what I can tell so far, the answer is yes — but only if you’re willing to measure success differently than you were trained to.
Your Turn: Apply This Today
Whether you’re in your first week or month 18, these disciplines separate product leaders who earn trust from those who burn goodwill:
- Schedule a “context download” with every key stakeholder in the first 30 days. Ask them one question: “What has every product leader before me gotten wrong?” Listen without defending. Take notes. Come back in 60 days to report what you’ve done about it.
- Map the informal power structure before you touch the org chart. Identify who the real decision-makers are — the people others defer to in meetings even when they don’t have the title. Build those relationships before you need them.
- Find one quick win in the first 45 days — and be transparent about why you chose it. Explain publicly that you picked it because it demonstrates capability and builds trust, not because it’s the most important thing. This earns more credibility than the win itself.
- Audit your predecessor’s decisions charitably. Before you change anything, write a one-paragraph explanation of why the previous decision made sense in its context. Share it with your team. It signals maturity and protects morale.
- Don’t reorganize anything in the first 90 days. No matter how obvious the fix looks. Reorgs before trust is established signal insecurity, not leadership. Earn the mandate first.
- Set explicit expectations about your decision-making rhythm. Tell your team how you make decisions, what you delegate completely, and what you always want to be consulted on. Ambiguity on this costs you more goodwill than any single wrong decision.
Navigating a product leadership transition — startup to enterprise, or joining a ministry organization with legacy tech? This is exactly the kind of work I help leaders think through. Let’s talk.