Category: Product Management

Teresa Torres has been making the case that product teams should map their Opportunity Solution Trees before touching a backlog. Her framework connects desired customer outcomes to specific opportunities, then branches into potential solutions — all documented visually before any feature decision gets made. The idea is simple: stop jumping to solutions before you’ve fully explored the problem space.

I’m a convert. I’ve watched teams build elaborate features for problems that weren’t actually blocking users from their desired outcomes. The OST discipline of separating “what are users trying to do?” from “what should we build?” saves months of wasted effort. If you’re not using opportunity solution trees in your discovery process, you should be.

But after running a 20-agent AI system and managing product decisions across a platform with tens of millions of users, I think Torres’ framework is missing a critical branch: execution complexity.

The Problem with Pure Opportunity Mapping

Torres’ methodology assumes that once you’ve identified the right opportunity and mapped potential solutions, implementation is relatively straightforward — map the problem space, explore solutions, pick the best one, ship it.

That works beautifully for traditional product features. It breaks down when you’re building AI-powered products where solution complexity can vary by orders of magnitude for the same opportunity.

Here’s a real example. Users were struggling to find relevant content quickly — a clear, validated opportunity. Torres’ framework surfaced three potential solutions: improved search filters, AI-powered recommendations, or a full personalization engine. All three theoretically addressed the same opportunity. But the execution complexity was radically different:

• Search filters: 2-week sprint with existing infrastructure
• AI recommendations: 3-month project requiring ML infrastructure we didn’t have
• Personalization engine: 12-18 months, new data team, significant architectural changes

The OST pointed toward the personalization engine as the most elegant solution. The execution reality made it the wrong choice — at least for that quarter.

The Execution Complexity Branch That’s Missing from Opportunity Solution Trees

Every opportunity solution tree needs a fourth assessment alongside feasibility, viability, and usability: execution complexity. Not just “can we build this?” but a structured evaluation of three dimensions:

Technical Complexity: What infrastructure, integrations, or architectural changes does this require? Does it introduce new dependencies that create fragility? AI solutions in particular can look simple on the surface but require entire data pipelines you haven’t built yet.

Organizational Capacity: Which specific people would work on this, and what are they not working on instead? “We have engineers” isn’t capacity analysis. You need to know if your ML team is already maxed out before you commit to an AI-heavy solution path.

Market Timing: How does this solution’s build timeline map to competitive pressure and user expectation shifts? The best solution shipped six months late is often worse than a good-enough solution shipped next sprint.

How This Changed a Real Decision

Back to the content discovery problem. The pure opportunity map pointed toward an AI recommendation engine. When I added the execution complexity branch, the picture shifted completely:

The recommendation engine required user behavior tracking we hadn’t built, content taxonomy infrastructure we didn’t have, and ML capacity that was already committed elsewhere for six months. Meanwhile, our data was showing users weren’t churning because of discovery problems — they were churning because of onboarding friction. That was a completely different branch of the opportunity tree we’d underweighted.

We shipped improved search filters in two weeks. Immediate impact on discovery success rates. ML capacity freed up for onboarding optimization. Six months later, we had the infrastructure foundation to revisit the recommendation engine with real behavioral data instead of assumptions.

Pure opportunity mapping would have sent us toward the most sophisticated solution. Adding execution complexity sent us toward the most effective one.

What I’ve Changed in Our Process

Every opportunity solution tree we build now includes an implementation branch with three required assessments before any solution advances to prioritization:

• Build vs. integrate: Can we solve this with existing tools and APIs, or does it require custom development?
• Team capacity reality: Named individuals, not abstract “team bandwidth”
• Dependency mapping: What other systems, teams, or external factors does this solution require before we can ship?

We also changed how we score solutions in prioritization. Instead of just evaluating opportunity impact, we multiply by an execution confidence score — a team-assessed number from 1-5 representing how clear and achievable the implementation path is right now, with current resources. High-confidence solutions get a boost. Novel solutions requiring infrastructure we don’t have get penalized, even if the opportunity mapping scores them well.

This has made our roadmap conversations significantly more honest. Teams stop selling “what would be most impressive” and start evaluating “what can we actually ship that moves the metric.” Those are different conversations.

Teresa Torres Is Still Right — Just Incomplete

None of this is an argument against opportunity solution trees. The framework is genuinely one of the most useful tools in product discovery, and Torres’ writing on continuous discovery should be required reading for any PM team.

The gap I’m pointing to is specifically about AI-era product development, where the distance between “this is the right solution” and “we can actually build this right now” has grown dramatically. AI solutions are rarely simple integrations. They carry data requirements, infrastructure dependencies, and organizational capabilities that need to be assessed as part of the tree — not after you’ve already committed to the direction.

Add the execution complexity branch. Your opportunity solution trees will be more honest and your roadmaps more achievable. If you’re already using deep customer knowledge to validate your opportunity space, adding execution complexity assessment closes the loop between discovery and delivery.

Your Turn: Apply This Today

Before your next opportunity solution tree session, add execution complexity as a first-class branch:

• Draw your OST with four branches, not three. Add “execution complexity” alongside desirability, viability, and feasibility. For each solution, map at least two execution risks: what could make this take 3x longer than estimated?
• Run a pre-mortem on your highest-priority experiment. Before you commit, ask the team: “Assume this experiment fails. What went wrong?” Write down the top three answers. Those are your execution risks. Address them in the experiment design.
• Estimate the “integration tax” on every proposed solution. How many other teams, systems, or processes does this solution touch? Every dependency adds execution time and coordination cost. Factor it in before you put a solution in a sprint.
• Create a “complexity score” for your backlog. Add a simple 1-5 complexity rating to every item: 1 = completely self-contained, 5 = touches 5+ systems or teams. Use it to balance your sprint with high-complexity and low-complexity items.
• Separate “solution discovery” from “execution planning” in your workflow. The OST is for discovery. Before any solution moves to execution, it needs a lightweight technical scoping session. Don’t skip the bridge between the two.
• Review your last three delayed projects and name the execution complexity that caused the delay. Was it dependencies, scope creep, unclear ownership, or something else? Use that pattern to inform how you scope the next one.

The execution complexity question is tactical, but it sits inside a bigger frame: what your product decisions are actually for — which shapes which trade-offs are even worth making.

Running product discovery at scale and hitting the gap between good frameworks and messy execution reality? I consult with product teams navigating complex build decisions, AI integration strategy, and discovery-to-delivery alignment. Let’s talk.

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.

I made the wrong paywall call once. We gated a feature that a significant portion of our free users relied on daily — not because the revenue math demanded it, but because “premium users should get more.” Six weeks later, support tickets had doubled, free-to-paid conversion had flatlined, and we’d punished the most engaged segment of our user base. We reversed the decision. It cost us three months and a lot of trust.

The freemium paywall framework I use today came out of that mistake. Here’s how I think about what should be free — and why getting this wrong kills mission-driven products faster than anything else.

The Wrong Question Behind Most Paywall Decisions

Most freemium decisions start from the wrong end. The instinct is reasonable: if you’re building a paid tier, paying users should get more. But when that logic drives every decision, you end up asking “what should go behind the paywall?” instead of “what must stay free?”

That inversion matters more than it sounds. When you start from the free side, you’re forced to defend every gate. When you start from the paid side, you’re incentivized to move things behind walls because it feels like value creation. In my experience, it usually isn’t.

The freemium products that last built genuinely useful free tiers first, then built paid tiers that made useful things faster, deeper, or scalable. The free tier wasn’t a demo. It was a product. If your free tier is deliberately limited to drive upgrades, you’re not running a freemium model — you’re running a time-limited trial. Those are different businesses, and they attract different users with different expectations.

Two Jobs, One Product

The framework starts with a question that sounds simple and isn’t: what job is the user trying to do?

In most digital products — especially mission-driven ones — at least two distinct user jobs show up at the same front door. The personal user and the professional. The student and the practitioner. The occasional reader and the daily power user. These aren’t tiers of the same job. They’re different jobs entirely.

Conflating them into a single pricing decision produces a product that serves neither well — and a paywall that frustrates the users most likely to become your strongest advocates.

Once you’ve mapped the jobs clearly, the paywall question becomes cleaner. For each feature, you’re really asking: does this serve the user who can’t pay, the user who won’t pay, or the user who pays because the tool is genuinely worth it?

Can’t pay: Gate this, and you’ve excluded someone with no alternative. If your product serves a global audience, this is a mission failure disguised as a pricing decision. Won’t pay: Gate this, and you’ll generate complaints with minimal conversions. The feature isn’t their tipping point. Pays because the tool is worth it: Gate this correctly and you have a sustainable model.

The Four Paywall Tests

For every feature — new or existing — I run four tests in order. The order matters.

Test 1: Access. Does gating this feature prevent someone from doing the core job they came here to do? If yes, it stays free. Not “probably free” — free, as a hard constraint. A product that charges for its core value has confused its business model with its purpose.

Test 2: Job. Is the primary user of this feature a personal user or a professional? Personal = free. Professional = paid. Students are a gray zone — check your analytics to see who actually uses it week over week. The data is almost always less ambiguous than the internal debate.

Test 3: Majority World. Would someone with limited income — a volunteer, a practitioner in a lower-income country, a student without institutional backing — need this feature to accomplish meaningful work? If yes, it belongs in the free tier or needs a genuine no-cost path. Scholarship programs, geographic pricing, and educator access are all legitimate answers. “We’ll figure that out later” is not.

Test 4: Revenue sufficiency. Is there a paying segment large enough and motivated enough that this feature can sustain itself economically? A feature behind a paywall that generates no conversions is worse than a free feature. It signals to free users that you’re extracting value while delivering no business result. As OpenView’s SaaS benchmarks consistently show, freemium-to-paid conversion depends heavily on the perceived value gap — not the friction gap.

The Ideology Under the Framework

The four tests are pragmatic. But there’s an ideology underneath them that determines how you handle the hard cases — and in mission-driven products, most hard decisions are edge cases.

The ideology I work from: subscribers are mission partners, not just customers.

When a professional user pays for a tool, they’re making it possible for others who can’t pay to access something valuable. That framing only holds if the free tier is genuinely good. If the free tier is deliberately weak to force upgrades, you’re not distributing access — you’re withholding it and calling it generosity.

This connects directly to how I think about subscription products for ministry — the paywall philosophy and the subscription model are two sides of the same decision. Get one wrong and you’ve undermined both.

Where AI Makes This Harder

Every product team is about to face a version of the same question: where does AI land in the framework?

The professional-tools category is relatively clear. AI features that accelerate professional workflows — research assistants, document generation, structured analysis — belong in paid tiers. The value is concrete, the willingness to pay is real.

The personal-use category is harder. An AI that helps someone understand a difficult concept or access something they couldn’t reach before — is that a professional tool, or is it closer to a core access feature? If you gate it, you’ve made a decision. That decision might be right for the business. It might not be right for the mission. Those aren’t the same thing, and pretending they always align is how you end up making the wrong call at the edge cases.

The products that age well are the ones that answered that question from the mission side first and built the revenue model around the answer.

The Clarity You Owe Your Users

The mistake I described at the start wasn’t really a pricing mistake. It was a clarity mistake. We hadn’t named what we believed about our users, so we defaulted to what we thought premium users deserved instead of what free users needed.

The framework above doesn’t eliminate that tension. It makes it visible. When you can map the jobs, run the four tests, and state the ideology out loud in a room with your team, you at least know what tradeoff you’re making.

Your Turn: Apply This Today

Walk your current or next paywall decision through this framework before your next pricing review:

• Categorize every feature as acquisition or retention. Go through your feature list and sort each into: “this brings users in” vs. “this keeps users coming back.” Acquisition features belong in free. Retention features belong in paid.
• Identify your “aha moment” and protect it. What is the single experience that converts a skeptic into a believer in your product? Make sure every user reaches it before they hit a paywall. If the aha is behind a gate, you’re metering the wrong thing.
• Map your mission-critical users. Who are the users whose engagement creates value for everyone else — contributors, creators, community members? Consider whether paywalling them is worth the cost to the overall ecosystem.
• Run a “free tier audit.” List everything currently free. For each item, ask: is this generating acquisition or just giving away margin? Remove or gate anything that isn’t actively driving new user acquisition or ecosystem health.
• Test your paywall message before your paywall decision. Show users a description of your paid tier before you build it. Does the value proposition make them lean in or shrug? If they shrug, you haven’t found the right gate yet.
• Set a paywall conversion benchmark. Decide in advance what free-to-paid conversion rate would validate your model. Build toward that number. If you hit 6 months without reaching it, revisit what’s behind the gate.

Navigating freemium strategy, pricing philosophy, or subscription model design? These are decisions I’ve made across multiple faith-tech products. Let’s think through it together.

If you’re measuring DAU for weekly products, you’re measuring the wrong thing — and it’s actively misleading your team. I spent thirteen years building products for pastors and ministry leaders across four continents, and for most of that time, I was using the wrong metrics.

At SermonCentral, our DAU looked terrible on paper. We were serving hundreds of thousands of active pastors — and our daily active user numbers were abysmal. Not because the product was broken. Because pastors prep sermons once a week, not every Tuesday at 3pm.

Most PM frameworks assume daily usage patterns. Retention curves calibrated for social media. Activation metrics borrowed from productivity tools. Engagement loops designed for apps people compulsively open.

If your users naturally engage weekly, those metrics aren’t just wrong — they’re actively misleading.

Why DAU for Weekly Products Fails

Here’s what I learned building SermonCentral: Sunday drives everything.

Sermon searches spike Monday through Wednesday. Downloads peak Thursday. Friday and Saturday? Ghost town. Sunday morning brings a flurry of last-minute mobile access, then complete silence until Monday.

Our DAU/MAU ratio never broke 20%. In consumer app terms, that’s death. For a weekly product serving hundreds of thousands of active pastors, it was exactly right.

The same pattern holds across every faith-based product I’ve built or analyzed. Church attendance is weekly. Small group meetings are weekly. Sermon prep follows a weekly rhythm that’s been consistent for centuries.

Your DAU will never look like Slack’s. That’s not a bug — that’s your users’ real spiritual and professional rhythm.

What Actually Matters: Weekly Active Metrics

After tracking both daily and weekly engagement across multiple products, here are three metrics that actually predict success for weekly-use products:

Weekly Active Sermon Searches (WASS) — At SermonCentral, we tracked unique pastors running sermon searches within their prep window (typically Monday–Thursday). This number stayed remarkably consistent week-over-week, even as DAU fluctuated wildly.

Sunday-to-Sunday Retention — Did the pastor who used your tool this Sunday also use it next Sunday? This 7-day cycle retention tells you more about product-market fit than any daily metric.

Content Action Rate within 48 Hours — Pastors who print, download, or save content within 48 hours of trial signup complete their first full prep cycle. The ones who don’t rarely convert to paid.

These patterns hold across different faith contexts too. When we analyzed usage patterns across regions — post-Christian Europe, Sub-Saharan Africa, Southeast Asia — weekly rhythms emerged regardless of cultural differences.

Daily vs Weekly vs Intermittent: Three Different Playbooks

I’ve built products across three different usage patterns, and each requires a completely different success framework:

Daily-use products (Bible reading apps, devotional tools): DAU matters. Optimize for habit formation, reading streak maintenance, daily content delivery.

Weekly-use products (SermonCentral, sermon prep tools, weekly group resources): DAU is meaningless. Optimize for prep-to-pulpit completion rates and Sunday-to-Sunday retention.

Intermittent-use products (discipleship tools triggered by life events, not calendar events): Neither daily nor weekly metrics capture the real value. A teenager might use a discipleship app three times in one week during a crisis, then not touch it for a month.

We spent two years trying to force SermonCentral into daily engagement patterns before accepting that the weekly rhythm was a feature, not a flaw. This connects directly to the broader challenge of product-market fit in faith tech — understanding what your users actually need versus what standard SaaS metrics say they should need.

The Real Activation Moment for Weekly Products

Most PM frameworks define activation as completing key actions in your first session. Sign up, upload a photo, connect with three people, send your first message.

For weekly products, that’s backwards.

A pastor who signs up for SermonCentral and browses illustrations on Tuesday hasn’t activated. A pastor who uses your research tool to prep Wednesday, builds a sermon Thursday, and preaches it Sunday has completed one full cycle. That’s your aha moment.

I started tracking what we called “First Sermon Sunday” — the percentage of trial users who completed a full prep-to-pulpit cycle within their first two weeks. This number predicted paid conversion better than any first-session metric we tested.

The activation window isn’t “first session.” It’s “first use cycle.” Andrew Chen’s research on retention and engagement confirms that retention curves look radically different depending on the natural usage frequency of your product category.

A Framework for Weekly Product Metrics

Step 1: Map your natural usage cycle. What’s the real-world rhythm your users follow? For pastors, it’s Sunday-to-Sunday. For small group leaders, it might be meeting-to-meeting. For Bible study groups, season-to-season.

Step 2: Design metrics around cycle completion. Instead of DAU, track users who complete full cycles. Instead of session length, track cycle-to-cycle retention. Instead of feature adoption, track cycle success rate.

Step 3: Time your interventions to the cycle. Onboarding emails on Monday morning, not immediately after signup. Retention campaigns on prep days, not random Tuesday afternoons. Feature announcements timed to the start of prep cycles.

Step 4: Report progress in cycle terms. “We had 2,847 active pastors this Sunday” tells a different story than “our DAU dropped 15% this week.” Both might be true. Only one reflects user reality.

The Deeper Insight

Spiritual formation follows rhythms, not funnels.

Product managers try to increase usage frequency because that’s what our metrics reward. But for faith-based products, the goal isn’t daily dependence — it’s weekly faithfulness. The goal is a product that fits how people actually live, worship, and grow.

Stop measuring DAU for products used once a week. Start tracking the metrics that matter: cycle completion, Sunday-to-Sunday retention, and the real activation moment when someone completes their first full use cycle.

Your engagement numbers might look terrible by consumer app standards. That might mean you’re building something that actually fits how people work and worship.

Your Turn: Apply This Today

Ready to move beyond DAU? Here’s how to start the conversation on your team:

• Audit your current metrics stack. List every metric in your weekly review. For each one, ask: does this capture whether users achieved their actual goal, or just whether they showed up?
• Define the “natural cadence” for your product. What is the genuine rhythm of value for your users? Daily? Weekly? Seasonally? Your core retention metric should match that cadence, not an industry benchmark.
• Pick one “mission completion” metric to track this quarter. Identify the single action that signals a user got real value. Track completion rate and the time-to-completion. Make it a weekly review staple.
• Have the stakeholder conversation proactively. Before your next leadership review, prepare a one-paragraph explanation of why your product’s success metric differs from DAU. Bring the alternative metric with 4 weeks of data.
• Segment by use case, not frequency. Separate users who access your product daily for lightweight tasks from those who use it intensively once a week. Track each segment’s success separately rather than averaging them together.
• Set a “dark usage” alert. Build or request a signal that fires when a high-value user hasn’t completed their key workflow in longer than their typical cadence. Absence at the right time is more meaningful than presence every day.

Building a product for ministry, church, or faith-based audiences? I consult with organizations navigating the intersection of product strategy, growth, and mission. Let’s talk.

In my role at FSI.co I deal with an overwhelming amount of data. To make it simpler, I’m going to focus on one segment of the data that I’ve been trying to get a grasp on so that I can help further our mission – to be known as the provider for polyurethane chemical systems.

I’m challenging our Digital Marketing Director to develop dashboards so the executive team can quickly see and digest how effective the marketing campaigns we run are. As I’ve been researching business intelligence further, I am beginning to understand that finding data points is often too easy, and throwing up random data on a dashboard lives in the primary stage of DATA.

Let’s back up here and explain the four stages of DIKW otherwise known as the Wisdom Hierarchy. This is a way of categorizing data into four distinct levels: Data, Information, Knowledge and Wisdom.

• Data is raw data that has not been organized or interpreted. For example, temperature readings in various regions.
• Information is data that has been categorized and organized according to certain criteria.
• Knowledge is “justified true belief”, as defined by Plato. It includes additional relational information such as correlations, causation, logic and conditions for the models to hold. This knowledge can then be put into actionable models which are a form of knowledge in themselves.
• Wisdom comes from being able to identify and apply this relevant knowledge in meaningful ways.

So how would all of this help us in this example of a dashboard I’m preparing to setup in the Marketing department?

I listened to a podcast recently where Forrester’s VP & Principal Analyst Ross Graber stated: “Our latest buying study showed us that on average buyers are going through 27 different motions before they make a successful purchasing decision.”

That statistic aligns with what I’ve been hearing for the last year or two. That 27 motions are not time boxed either. As an example, one of our chemical systems is such a large scale decision that it takes roughly 5 years to move the purchasing organization along the buyer’s journey from Awareness to Decision.

My goal with setting up the dashboard is to be able to identify these 27 interactions and see where we can help answer questions or minimize risks, fears, anxieties the business may have. How can we turn a 5 year decision into a 2 year decision?

That is where wisdom is in the DIKW hierarchy.