There’s a conversation happening in every engineering team building AI products right now, and most PMs aren’t in it.

It’s about tokens — specifically, how many to send, how many to generate, and what happens to your product when you get that decision wrong.

For most of AI’s current wave, token management was treated as an infrastructure concern. Engineers handled it. PMs wrote product specs, engineers figured out how to call the model efficiently, and both sides pretended this was a clean division of labour.

That pretense is breaking down.

Why token budgets have become a product decision

When you call a large language model, you’re sending a context window — everything the model knows about the current task. That context has a ceiling. Exceed it, and the model can’t process the full input. Approach it, and quality degrades. Stay well inside it, and you’re leaving capability on the table.

The cost dimension makes this sharper. Tokens cost money. In simple single-turn interactions, the cost is small and the context management is trivial. In agentic workflows — where an AI agent calls other AI agents, accumulates tool outputs, maintains conversation state — the token count compounds with every step. A workflow that costs $0.004 per run in testing can cost $0.40 in production when real conversation length and tool use are factored in. Scale that to 10,000 daily users and the economics are suddenly a board-level conversation.

But cost is the tractable problem. The quality failure is subtler.

What actually breaks

I’ve watched two failure modes emerge repeatedly as teams try to scale AI features beyond prototypes.

The first is context bloat. The team is cautious — they want the model to have everything it might need. So they include full conversation history, all user metadata, every system instruction, the complete document the user uploaded. The model works beautifully in testing, which is always with short conversations and clean inputs. In production, conversations get longer. Documents are bigger. The context window fills. When it does, models don’t throw an error — they start quietly losing the thread. Recent instructions get deprioritised in favour of earlier context. The model gives confident answers that contradict what the user said three messages ago.

The second failure is aggressive truncation without strategy. The team hits costs and decides to cut context. They start dropping earlier messages, summarising conversation history, trimming system prompts. But they do it arbitrarily — cutting by recency rather than relevance. Now the model loses the part of the conversation that actually mattered. A user says “as I mentioned earlier, the invoice date needs to match the LC” — but “earlier” was truncated. The model confidently ignores the constraint. The error surfaces to a user, not a developer.

Both failures share a root cause: the team never asked what the model actually needs to know at each step.

The framing that helps

Think of token budgets the way good engineers think about memory architecture.

You have fast, expensive memory (RAM) and slow, cheap storage (disk). Good system design isn’t “put everything in RAM just in case.” It’s “put in RAM exactly what’s needed right now, and design a retrieval path for everything else.”

Applied to AI systems: what does the model need in context right now? What can be retrieved on demand using vector search or a tool call? What should be compressed into a summary rather than passed verbatim? What can be dropped entirely because it’s no longer relevant to the current task?

These aren’t engineering questions. They’re product questions — because the answers determine what the user experience feels like. A model with a well-managed context window feels coherent, consistent, responsive. A model with a bloated or arbitrarily truncated context feels unreliable, even when the underlying model quality is identical.

Where PMs need to be in this conversation

The practical intervention isn’t for PMs to become token engineers. It’s to include token budget decisions in product design — not as an afterthought, but as a first-class constraint alongside latency and accuracy.

This means asking, when designing an AI feature: what’s the longest realistic conversation this feature will have? What context will accumulate over time? At what point does the context become a liability rather than an asset? What’s the strategy for handling that?

It also means building observability into the product from day one. If you can’t see what your model is receiving in context during a production failure, you cannot debug it. Token count per call, context composition, truncation events — these should be as visible as response time and error rates.

The teams getting AI features into reliable production are treating token management as a product design constraint. The teams still struggling are treating it as a backend implementation detail someone else will sort out.

It’s not. And the sooner PMs own that, the fewer expensive surprises they’ll ship to users.

Most AI assistant setups fail for the same reason most productivity systems fail.

They’re built for a fantasy version of you — someone with infinite patience to prompt, review, approve, and babysit. The real you has 47 things competing for attention and zero tolerance for friction.

I spent the last week building a personal AI assistant. Not a chatbot. Not a “co-pilot” that waits for instructions. An actual assistant — one that shows up proactively, handles tasks autonomously, and knows when to ask versus when to just do.

Here’s what I learned about designing AI systems you can actually trust.

The Problem With Most AI Setups

There are two failure modes I see constantly:

Too dumb: The AI can only respond when you ask. You’re still the one remembering to check things, triggering workflows, and doing the coordination work. You’ve added a tool, not removed load.

Too dangerous: The AI has access to everything and can do anything. One hallucination, one misunderstood context, and it’s sending emails to clients or deleting files you needed.

Most people oscillate between these extremes — either micromanaging their AI or giving it access they later regret.

The missing piece isn’t better prompts or fancier models. It’s system design — specifically, designing the boundaries of autonomy.

The Three Questions That Shaped My System

Before I touched any tools, I forced myself to answer three questions:

1. What decisions am I comfortable delegating completely?

Not “what tasks” — decisions. Tasks are mechanical. Decisions require judgment.

For me: prioritising what research to surface, deciding when a task is urgent enough to interrupt me, choosing what context to include in a morning briefing. These are judgment calls, but low-stakes ones. If the AI gets them slightly wrong, I lose a few minutes, not a relationship or a deal.

2. What actions should never happen without my explicit approval?

Anything that leaves my “system” and touches the outside world with my identity attached. Sending emails. Posting publicly. Scheduling meetings with other people.

The heuristic: if a mistake here would require me to apologise to another human, it needs approval.

3. Where do I actually lose time to friction — not to the work itself?

This one surprised me. I thought I’d automate the “big” tasks. Instead, the biggest wins came from eliminating transitions — the mental overhead of context-switching between tools, remembering what I was supposed to check, and pulling together information scattered across five different places.

What Autonomy Actually Looks Like

My assistant — I call her Mira — now handles three categories of work without asking:

Daily orientation: Every morning at 8am, she sends me a briefing. Weather, calendar overview, priority tasks, and one piece of research relevant to what I’m working on. I didn’t ask for this. She just shows up.

Research accumulation: Every afternoon, she appends fresh research to a running document. AI developments, fintech news, workflow ideas. I never have to “remember to research.” It just accumulates.

Task capture: When I voice-note a task into Telegram, it appears on my task board. Correctly categorised. No friction. I don’t even open the task app most days.

None of this is magic. It’s plumbing — connecting systems that already existed. But the design is what makes it useful: she operates within clear boundaries, on a predictable rhythm, with outputs I can trust without reviewing.

The Approval Matrix

Here’s the framework I use to decide what gets automated vs. what requires my sign-off:

Low stakes if wrongHigh stakes if wrongReversibleFull autonomyAutonomy with loggingIrreversibleApproval with suggestionHard block — I do it myself

Full autonomy: Mira can read my email, research topics, organise files, and update my task board. If she gets something wrong, I can fix it in seconds.

Autonomy with logging: She can modify documents and add calendar events, but I can see exactly what changed. Mistakes are visible and reversible.

Approval with suggestion: She can draft an email or propose a meeting time, but I press send. She does the work; I own the decision.

Hard block: Anything public-facing, anything that commits me to other people, anything that deletes without backup. She doesn’t touch these.

This matrix isn’t about the AI’s capability. It’s about my risk tolerance and the cost of mistakes.

What I Got Wrong Initially

Two mistakes worth sharing:

Mistake 1: Automating tasks instead of decisions.

My first instinct was to automate outputs — generate this report, send this summary. But the real leverage came from automating inputs — what information reaches me, when, and in what form.

When you automate outputs, you still have to review everything. When you automate inputs, you change what you’re even thinking about.

Mistake 2: Designing for capability instead of rhythm.

I initially built Mira to respond to requests. But the most valuable thing she does is show up unprompted at specific times — morning, mid-afternoon, evening. Not because I asked, but because that’s when I need orientation.

The best AI systems aren’t reactive. They’re rhythmic.

The Design Principle That Changed Everything

Here’s the line I keep coming back to:

Presence matters more than tasks.

I don’t need an AI that can do everything. I need one that shows up at the right moments with the right context, and otherwise stays out of the way.

That meant designing for fewer interactions, not more. Consolidating information instead of scattering it. Batching instead of interrupting.

Mira sends me three messages a day, max. That constraint forced better design than any capability expansion would have.

What This Means for You

You don’t need to build what I built. The tools don’t matter — I used a mix of automation platforms, messaging apps, and cloud storage that fit my existing workflow.

What matters is the thinking:

1. Start with decisions, not tasks. What judgment calls are you comfortable delegating?

2. Design for rhythm, not reaction. When do you need information to show up, unprompted?

3. Use the approval matrix. Map every potential AI action to a quadrant. Be honest about what’s actually reversible.

4. Constrain on purpose. Fewer touchpoints, tighter boundaries, more trust.

The goal isn’t an AI that can do everything. It’s an AI you don’t have to think about — because you’ve already thought through what it should do.

I’m working on a detailed implementation guide for those who want to build something similar — the actual tools, the specific workflows, and the configuration that makes it work. If that’s interesting, reply and let me know what you’d want it to cover.

Every PM I talk to asks the same question: “Am I using AI enough?”

Wrong question.

The real question is: “Am I using AI well?”

There’s a difference between touching AI tools daily and actually being fluent. Most frameworks confuse activity with capability. They measure how often you prompt ChatGPT, not whether you’re making better decisions because of it.

I built the Practical AI Fluency Framework (PAFF) after watching dozens of mid-career professionals—PMs, operators, founders—struggle with this gap. They weren’t beginners. They’d tried the tools. But they had no way to know if they were actually good at this, or just going through motions.

The problem with existing frameworks

Academic frameworks are too theoretical. They teach you what transformers are. You don’t need to know how an engine works to drive a car well.

Tool-focused frameworks are too narrow. They teach you ChatGPT tricks. But fluency isn’t about memorizing prompts—it’s about knowing when AI helps and when it doesn’t.

Generic frameworks miss context. A marketer’s AI fluency looks different from a PM’s. Same tools, different judgment calls.

What was missing: a framework that measured real-world capability for people who need to use AI to do their jobs better, not become AI engineers.

What AI fluency actually means

After building AI workflows for LexiMoney, automating parts of my own product work, and helping other PMs integrate AI into their processes, I kept seeing the same five capabilities separate effective AI users from people just experimenting:

1. Strategic Delegation – Knowing what to give to AI vs. what to keep human. This isn’t “can AI do this?” It’s “should I let it?”

A beginner delegates obvious tasks: “write this email.” An expert designs hybrid workflows where AI handles research synthesis while they make the strategic call on what it means.

2. Effective Communication – Getting quality results from AI. Not memorizing prompt templates. Understanding how to articulate requirements, provide context, and iterate when the first output misses.

I’ve seen PMs write 50-word prompts that get garbage. I’ve seen others write 10 words that get exactly what they need. The difference isn’t prompt engineering knowledge—it’s clarity of thinking.

3. Critical Discernment – Spotting when AI is wrong. Every AI output contains decisions about what to include, emphasize, or skip. Can you catch when it hallucinates a data point? When it misses a critical edge case? When “good enough” isn’t actually good enough?

This is where most people fail. They treat AI like Google: if it returned a result, it must be right.

4. Workflow Integration – Building AI into daily work, not just using it occasionally. Do you have repeatable processes? Can you measure the impact? Have you documented what works so you’re not reinventing it every time?

The difference between someone who “uses AI” and someone who’s actually fluent: workflows. Documented, repeatable, measured.

5. Responsible Practice – Using AI ethically and safely. Do you know when you’re about to paste sensitive customer data into ChatGPT? Do you disclose AI assistance when it matters? Do you catch bias in outputs?

This matters more as AI becomes infrastructure, not experiment.

Why scoring matters

Most frameworks give you concepts. PAFF gives you a score: 0-100 across these five competencies.

Not because scores are inherently valuable, but because you can’t improve what you don’t measure.

When someone scores 45/100, they’re not “bad at AI.” They’re probably an Intermediate user—using AI daily, seeing some value, but without systematic approach or optimization. That’s the middle 40% of professionals.

The score tells them exactly where the gaps are:

• Weak at delegation? You’re probably doing too much manually.

• Weak at discernment? You’re shipping AI errors you don’t catch.

• Weak at workflow integration? You’re not capturing the full productivity gain.

And because it’s benchmarked against peers in your role and experience level, you know if you’re behind, average, or ahead.

The insight that changed how I built this

Initially, I was building separate frameworks for PMs, marketers, sales folks. Different assessments, different competencies.

Then I realized: the competencies are universal. Strategic delegation, effective communication, critical discernment—these apply across roles.

What changes is the application.

A PM delegates user research synthesis. A salesperson delegates prospect research. Different tasks, same judgment: knowing what AI should handle vs. what needs human expertise.

So PAFF uses one framework, five competencies, role-specific examples. You get scored on universal capabilities, benchmarked against your specific peer group.

What this means for your AI decisions

If you’re a PM wondering “should I be using AI more?”—wrong frame.

Better questions:

• Can you identify which of your recurring tasks AI should handle?

• When AI gives you output, do you catch the errors?

• Have you built any repeatable AI workflows, or are you winging it every time?

• Can you measure how much time AI actually saves you?

These aren’t tool questions. They’re judgment questions.

AI fluency isn’t about touching more tools. It’s about making better decisions about when and how to use the tools you already have.

Most professionals are stuck at Intermediate (36-60 points): using AI daily, but without strategy, verification, or measurement. They know they should be getting more value. They don’t know how.

The framework gives them a map. Not to learn AI. To use it well.

Dipender

P.S. — I’m opening early access to PAFF this week. If you want to see where you actually stand (not where you think you stand), reply to this email. I’ll send you the assessment link when it’s live.

Every product cycle has its shiny object. Today it’s AI — specifically LLMs. Teams rush to bolt them onto everything: search, workflows, chatbots, dashboards. But here’s the trap: not every problem needs AI.

The best product leaders know this. They don’t start with the tech. They start with the problem.

The seduction of over-engineering

There’s a pattern I’ve seen in both startups and enterprises. A new technology comes along, and suddenly every roadmap has to “leverage” it. The result? Complex, brittle features that slow teams down and confuse users.

It’s the product version of using a sledgehammer to push in a thumbtack.

A better lens: input → output → scale

Instead of asking, “Can we add AI here?”, ask three simpler questions:

1. Input: What kind of data are we dealing with? Is it structured, predictable, or messy and ambiguous?

2. Output: What does the user actually need back? Precision? Explanation? A decision?

3. Scale: Does solving this with AI materially change speed, cost, or accessibility at scale?

Most of the time, simple rules, heuristics, or deterministic workflows solve the problem cleaner and faster. AI should only enter when the problem space is truly fuzzy — where rules break down, patterns are non-linear, or scale makes manual approaches impossible.

Simplicity compounds trust

Users don’t care if your feature runs on an LLM or a spreadsheet macro. They care if it works reliably, explains itself, and makes their life easier.

Over-engineering doesn’t just waste resources. It erodes trust. Products feel experimental instead of dependable.

The discipline is in restraint. The courage to say: this doesn’t need AI yet.

The takeaway

Good product management isn’t about chasing every new tool. It’s about matching the smallest, clearest solution to the problem at hand.

Sometimes that’s AI.
Often, it’s not.

When we hear “Central Bank Digital Currency” (CBDC), the conversation often jumps to big outcomes: financial inclusion, de-dollarization, faster cross-border payments. But as a product person, I find it useful to pause and ask a simpler question: how is this thing actually being built?

Because beneath the hype, CBDCs are products. They are designed, tested, and iterated on—just like the apps and platforms we use daily. And understanding their architecture reveals both the opportunities and the trade-offs central banks face.

1. Two-Tier Model: The Distribution Choice

Most retail CBDCs are being explored as a two-tier system.

• The central bank runs the core ledger and issues the digital money.

• Private players—banks, fintechs, wallet providers—deliver the user-facing experiences.

This mirrors how app stores or payment rails work. The platform (central bank) provides trust and settlement finality, while the ecosystem (private sector) provides usability and innovation.

Why does this matter? Because if CBDCs went direct-to-consumer, they could hollow out commercial banks. The two-tier model avoids that risk and leverages existing distribution.

2. APIs as the Interface Layer

Project Rosalind (led by the BIS) showed how APIs can be the connective tissue in a CBDC ecosystem. Think of APIs as the rails that let wallets, merchants, and banks plug into the central bank’s ledger.

From a product lens, this is the equivalent of deciding whether to build a closed platform (like early Apple) or an open one (like Android). CBDC APIs need to balance standardization (so systems can interoperate globally) with flexibility (so providers can innovate on top).

This is not trivial. A too-rigid design kills innovation; too-open creates fragmentation.

3. Access Enablers: A New Category of Intermediary

Project Sela introduced the idea of Access Enablers—entities that provide onboarding, KYC, and customer interfaces without actually holding customer funds.

This is a fascinating design choice. By unbundling “customer service” from “liquidity management,” CBDCs could open the door for a much wider set of players—fintechs, telecoms, even big tech—to participate in distribution.

In product terms, it’s like lowering the barriers for third-party developers to build on your platform. More participants usually mean more use cases, faster. But it also raises governance and cybersecurity questions.

4. The “Clean Slate” Opportunity in Cross-Border

The most ambitious promise of CBDCs is in cross-border payments. Today, they are slow, costly, and opaque because they run on a patchwork of correspondent banking networks.

CBDCs offer a “clean slate”: if countries coordinate designs upfront—common standards, interoperability, messaging protocols—they could bypass decades of legacy inefficiency.

But here’s the catch: if each central bank builds in isolation, we risk recreating the same fragmented mess we already have. From a product lens, it’s like building dozens of chat apps that can’t talk to each other.

5. Lessons for Builders

Stepping back, what does this teach us as product people?

1. Distribution matters as much as the core product. A CBDC ledger without private sector participation is like a platform without developers—technically sound, but practically irrelevant.

2. Interfaces define adoption. APIs and wallets will make or break CBDCs, not the cryptography behind them.

3. Design choices have second-order effects. Decide to let intermediaries in, and you get innovation plus complexity. Decide to exclude them, and you risk stagnation.

4. Interoperability must be intentional. Without early alignment, you get silos. With alignment, you get networks.

Final Thought

CBDCs are not just a monetary experiment. They are a live case study in how to design public infrastructure as a product—balancing trust, innovation, and usability.

And that’s why, even if you don’t care about monetary policy, it’s worth studying them. They show us how product thinking is becoming essential even in domains once thought to be purely regulatory or political.

Because at the end of the day, money too is a product. The question is: who designs it best?

We talk a lot about technical debt. But most product teams quietly accumulate something more dangerous — decision debt.

It’s the backlog of unmade, unclear, or postponed decisions that keep compounding until momentum stalls. And it rarely shows up on dashboards.

I first started noticing it in teams that looked busy, but weren’t really moving. JIRA was full. Sprint velocity seemed healthy. But meaningful outcomes were absent. Everything took longer. Scope kept shifting. Teams got caught in meetings debating the same unresolved points. That’s when it clicked — we weren’t slow because of poor execution. We were dragging invisible weight: a debt of unmade decisions.

What is decision debt?

It's what builds up when:

• We avoid making tough calls

• We push decisions downstream to buy time

• We keep options open too long

• We leave open questions in PRDs, roadmaps, or discussions

• We delay clarity in the name of collaboration or consensus

The problem? Every unclear decision becomes a hidden tax on the system. Engineers second-guess requirements. Designers hedge on edge cases. PMs run extra meetings just to clarify what’s actually being built.

And like all debt, it compounds — quietly and consistently. One unclear tradeoff creates five clarifications, ten Slack threads, and a dozen downstream adjustments.

Why it’s so common

Startups especially fall into this because we want to stay flexible. We prize speed, adaptability, and collaboration. But clarity is what creates speed. Without it, flexibility turns to chaos.

What’s worse — many PMs are rewarded for delivering fast, not deciding well. So they avoid committing. They default to documenting "options" instead of calling the shot. In the short term, it feels safer. In the long term, it erodes trust and velocity.

How to pay it down

You don’t need a perfect process. You just need a culture that values decision velocity.

Here’s what I try to apply:

• Make small, irreversible decisions fast. Don’t overthink low-risk calls.

• For big bets, frame the decision clearly: what are we choosing, why now, and what are we saying no to?

• If something’s blocked, ask: “What decision haven’t we made yet?”

• In PRDs or team syncs, make tradeoffs explicit — ambiguity breeds debt.

• When revisiting past choices, be honest: did we dodge this earlier?

The best PMs aren’t just great at managing stakeholders or shipping features. They’re great at creating clarity. That means naming tradeoffs, committing when needed, and revisiting old debt before it slows the team down.

Most product decisions don’t fail because of execution. They fail because of assumptions — the kind that slip in quietly, get repeated often, and eventually become default.

In fast-moving teams, we optimise for momentum: timelines, launches, incremental improvements. And in the process, we often inherit ways of thinking — about users, flows, pricing, edge cases — without revisiting whether the fundamentals still hold.

That’s where first principles matter. Not as a theoretical concept, but as a tool to clear the fog.

First principles aren’t about big bets. They’re about clarity.

People assume first principles thinking is only for solving hard problems or building something new. In reality, it’s more useful in the day-to-day — especially when things seem obvious.

It’s a practice of asking:

• What are we assuming here?

• What has to be true for this to work?

• Are we solving the right layer of the problem?

That small pause in thinking often avoids weeks of rework downstream.

Defaults aren’t neutral — they compound.

Over time, teams build muscle memory: how we scope features, handle edge cases, define “done”. Many of those defaults were created under different contexts — but we rarely stop to re-evaluate them.

That’s where issues creep in:

• We solve UX problems that are actually awareness gaps.

• We ship features that mimic competitors but don’t serve our user journeys.

• We prioritise speed over clarity — and end up with faster cycles of shallow iteration.

When you work from first principles, you don't automatically reject the default. You just revalidate it. And that alone improves the quality of decisions.

It shows up in small ways:

• In writing PRDs, it helps avoid over-scoping by forcing us to separate core from nice-to-have.

• In growth discussions, it cuts through noise by asking: what problem are we really solving with this new lever?

• In customer support workflows, it forces clarity on who the user is at that moment — not in a persona deck, but in the real context.

These aren’t big, philosophical changes. But they reduce drift. They bring focus back to fundamentals.

A simple practice:

When making any decision — especially fast ones — just ask:

“What assumptions are baked into this?”

You don’t need a workshop. You just need a moment of clarity.
And that moment often saves you from solving the wrong problem well.

This isn’t about overthinking. It’s about intentionality.
And in high-velocity teams, intentionality is often the first thing sacrificed.

Start there. Not with frameworks, not with tools — just with a habit of asking better questions.

It compounds.

Cross-border payments remain frustratingly inefficient despite the fintech boom. Whether you’re an Indian student paying tuition via LRS, a global business making international remittances, or a fintech company optimizing SWIFT transactions, you’ve likely encountered:

✔ Hidden fees & unfavorable forex rates
✔ Slow settlements (often taking 2–5 days)
✔ Opaque banking processes with no tracking

💡 With real-time domestic payments (like UPI in India) becoming instant, why is international money movement still broken? Let’s break it down.

📊 The Cross-Border Payment Bottleneck: SWIFT, LRS & Banking Delays

Despite fintech advancements, most international transactions still rely on outdated banking rails.

1️⃣ Why SWIFT Transfers Are Expensive & Slow

• Correspondent banking fees: SWIFT transactions often pass through multiple intermediary banks, each taking a cut.

• 2–5 day processing time: Unlike UPI, which is instant, SWIFT-based transfers involve multiple approval steps.

• Opaque fees: Banks don’t disclose exchange markups transparently, increasing costs.

2️⃣ How RBI’s LRS Impacts Outward Remittances

The Liberalized Remittance Scheme (LRS) governs how much money Indian residents can send abroad.

• LRS cap: $250,000 per year for education, travel, and investments.

• TCS (Tax Collected at Source) rules impact forex remittances.

• Banks vs. fintechs: Traditional banks dominate LRS payments, while fintechs are slowly entering.

📌 Key Problem: Even though fintechs like Wise & Nium claim to offer low-cost remittances, they still depend on traditional banking infrastructure, meaning they can’t bypass the inefficiencies of SWIFT.

🚀 The Future of Cross-Border Payments: What’s Changing in 2025?

✅ 1. UPI, Pix & Instant Payment Networks Going Global

Governments are linking domestic real-time payment systems (RTPs) across countries, reducing dependency on SWIFT.

✔ UPI-PayNow (India & Singapore): Near-instant international money transfers.
✔ PIX (Brazil), FedNow (US): New instant settlement systems expanding.
✔ Challenges: Most RTPs are still regional, and adoption takes time.

💡 The Opportunity: If UPI expands to more countries, outward remittances from India could become faster & cheaper than SWIFT.

✅ 2. CBDCs & Blockchain – The Future of Global Money Movement?

With over 130 countries exploring Central Bank Digital Currencies (CBDCs), the big question is:

💡 Will CBDCs replace SWIFT & LRS payments?

Potential Benefits:
✔ Instant global transfers (no intermediary banks).
✔ Lower transaction costs (government-backed stable money).
✔ Better compliance tracking (AML/KYC built-in).

Challenges:
⚠ Not all CBDCs will be interoperable – China’s Digital Yuan and India’s Digital Rupee aren’t integrated with global systems yet.
⚠ Private stablecoins (USDC, USDT) are still leading in cross-border crypto payments.

📌 What This Means for Fintechs: While CBDCs are promising, they won’t disrupt SWIFT & LRS until governments agree on global standards.

🌍 What Needs to Change for Cross-Border Payments to Improve?

For faster, cheaper international payments, these three areas must evolve:

1️⃣ Interoperability Between Payment Systems

• Expand UPI-like networks globally (India-Singapore is a great start).

• Build fintech solutions that integrate directly with RTPs, bypassing SWIFT.

2️⃣ Regulatory Alignment for Faster Transactions

• Governments must streamline AML/KYC compliance, so banks don’t delay transfers.

• India’s LRS & tax rules need modernization to reduce payment friction.

3️⃣ More Innovation in Fintech Remittance Models

• Fintechs must move beyond FX markups & SWIFT rails to adopt blockchain & smart contracts.

• DeFi-based remittance startups could challenge banks if regulations allow.

💡 Final Thoughts: The Next Decade of Cross-Border Payments

We’re at an inflection point where technology is available, but regulation and banking systems are still catching up.

🚀 The real question isn’t whether cross-border payments will improve—it’s who will drive the change.

What’s your take? Drop your thoughts in the comments or reply to this newsletter.

📩 Found this useful? Subscribe to Digital & Beyond for more insights on fintech, product management, and the future of money.

These days, it feels like everyone’s chasing “more”—more productivity, more connections, more options. But think about it: all this noise often just distracts us from what really matters. Simplicity, on the other hand, might seem like it’s taking the easy road, but in reality, it’s about creating a clearer path to focus, purpose, and impact.

1. Clarity Through Simplicity

When things are simple, it’s like a fog lifts. Instead of getting lost in the details, simplicity gives us focus. In business, that can mean sticking to a core problem instead of cramming in every feature under the sun. It’s easy to get caught up in trying to please everyone or solve every problem at once. But stepping back and asking, “What’s essential here?” clears the way. It’s no wonder people like Steve Jobs pushed for simplicity so much—clean thinking leads to clean outcomes, something that benefits everyone involved.

2. Simplicity Saves Time and Energy

We’ve all been there: juggling overlapping projects, managing priorities that seem to change by the minute. It’s exhausting. Simplicity, though, is a hidden strength. When you’re focused on what really counts, decisions come faster, with less stress. A simpler schedule or a straightforward plan lets us channel energy into what makes a difference. That’s something people feel in their daily routines—cutting out the “extra” doesn’t just save time, it brings a sense of calm that can be rare in today’s fast-paced world.

3. True Innovation Often Comes from Simplicity

Some of the best ideas are the simplest ones. Take a look at the products you really love. More often than not, they’re the ones that solve a specific problem in a way that just works. In a world that’s often tempted to add bells and whistles, sticking to the basics can be a game-changer. It’s not about creating something flashy; it’s about solving real problems in ways that people can connect with right away.

4. Making Space for What Matters

Outside of work, simplicity can mean a lot of things. Maybe it’s about cutting down on commitments or letting go of habits that don’t add value. A simpler lifestyle opens up room for things that bring meaning, like spending quality time with loved ones or investing in personal growth. When you choose quality over quantity, life feels a bit fuller, more intentional.

So, How Do You Embrace Simplicity?

The beauty of simplicity is that it’s within reach for everyone. It’s about asking a few key questions—like “What’s essential here?” or “Does this add real value?” These small shifts can create huge changes, whether it’s in business strategies, product decisions, or just day-to-day life.

Simplicity might seem quiet, but it’s far from basic. It gives us the focus to go deeper and create work, relationships, and lives that feel meaningful. So, next time everything feels overwhelming, remember that sometimes, the smartest choice is to keep it simple. Not only will life be easier—it might just be more fulfilling, too.

Photo by Eva Mauermann

You’ve heard it before: “What’s easy to do is easy not to do.” But what does it really mean? At first glance, it sounds obvious, maybe even trivial. But the simplicity hides something much deeper—an insight that can change the way you approach building products, managing teams, and even your own personal growth.

The essence of this phrase lies in the small actions, the daily habits, and the minor decisions we often overlook. We tend to believe that success is built through monumental achievements. But more often, it’s the small, seemingly insignificant actions that make all the difference.

Let’s break it down and explore why understanding this idea can transform your work and your life.

Small Actions Compound Over Time

The truth is, most things that are easy to do—like replying to a quick email, writing down an idea, or spending 15 minutes learning something new—don’t feel urgent. They’re so simple that we push them aside. We think, “I’ll do it later. It’s not a big deal.” And because they’re easy, they’re also easy to skip. But skipping them has a cost, one that builds up over time.

Take daily progress on a product, for example. You could spend 30 minutes each day refining a user story, cleaning up a feature backlog, or engaging with users for feedback. It’s easy to do. But it’s also easy to say, “I’ll deal with it tomorrow,” and that’s where things start to pile up. You don’t feel the effect immediately, but over time, it adds up. Small actions, repeated consistently, compound like interest in a bank account.

That 30 minutes each day may not feel like much in the short term, but over a month, that’s 15 hours. And over a year? You’ve got yourself a habit that significantly moves your product forward.

The lesson here: Small, consistent actions lead to big outcomes over time. If you neglect them, you lose the compounding effect that could have propelled you ahead.

Avoid the Trap of “It Doesn’t Matter”

One of the biggest traps we fall into is thinking that the little things don’t matter. Writing one email, checking in with one team member, or reading one article won’t make or break your day, right? But this mindset misses the point. Each small action is like a brick in a wall. Skipping one brick may not be catastrophic, but skip enough, and the wall never gets built.

Think about how easy it is to ignore user feedback early on in the development process. “We’ll fix that later,” you tell yourself. But each ignored piece of feedback is a missed opportunity to improve your product. Over time, those missed opportunities compound into a product that’s out of touch with your users' needs.

What’s easy not to do is easy to ignore until it’s too late. At that point, you find yourself scrambling to fix what could have been prevented through small, daily actions.

The takeaway: Don’t underestimate the power of small actions. Each one contributes to the bigger picture, and over time, they build up to something significant—whether that’s success or failure.

Building the Discipline of Small Actions

If small actions are so important, why do we skip them? The answer lies in discipline. It’s not that the actions are hard; it’s that building the discipline to do them regularly is hard. This is where most people struggle. It’s not about a lack of skill or talent—it’s about consistency.

Discipline comes from recognizing the importance of small actions and committing to doing them, even when they seem unimportant. It’s showing up every day, whether you feel like it or not. It’s writing one paragraph for that blog post, making one call to a potential partner, or spending 10 minutes reviewing data.

In product management, this discipline is critical. You might not always feel like refining your roadmap or checking analytics, but the small, daily efforts are what keep your product moving in the right direction.

Pro tip: Create habits around the small actions. For example, dedicate the first 15 minutes of your day to reviewing the product backlog or checking in with your team. Over time, these actions become automatic, and the discipline becomes second nature.

The Ripple Effect of Small Actions

One of the most powerful aspects of small actions is their ripple effect. When you take small steps consistently, you inspire those around you to do the same. If your team sees you making progress every day, they’re more likely to follow suit.

In startups, where resources are tight and time is precious, these ripples can be game-changing. A single email can open the door to a new opportunity. A short user survey can reveal a key insight that improves your product. A daily stand-up meeting can keep the entire team aligned and moving forward.

You don’t always see the immediate effects of these actions, but over time, they create momentum. And momentum is what separates successful teams and products from those that fizzle out.

Overcoming the “Easy Not to Do” Mentality

So how do you overcome the inertia of small actions being “easy not to do”? It starts with a mindset shift. You have to stop thinking of small tasks as unimportant. Instead, recognize them as the building blocks of your success.

Start by identifying a few small actions that you know are easy to do but that you’ve been putting off. Maybe it’s sending that follow-up email to a client or spending 15 minutes each day refining your pitch deck. Then, commit to doing them daily for a week. Track your progress, and notice how much easier it becomes to maintain consistency.

Once you’ve built the habit, the momentum will take over. What was once easy to skip becomes something you naturally do without thinking.

Final Thoughts

The discipline of small actions is one of the most underrated aspects of success. It’s not flashy, and it’s not exciting, but it’s incredibly effective. Whether you’re a founder building a company or a product manager leading a team, mastering this discipline can set you apart.

Remember, what’s easy to do is easy not to do—but that doesn’t mean it’s any less important. The small actions you take today are the foundation of the big successes you’ll have tomorrow. So, don’t skip them.

Let’s get to work.

Building a great product is hard. As a founder or product manager, you know that success isn’t just about having a brilliant idea—it’s about how you execute it. And the execution often boils down to the people driving it forward: the product managers.

Over the years, I’ve come to see that there isn’t just one type of product manager (PM). We tend to fall into different personas based on our strengths, weaknesses, and the ways we think. And knowing which persona you embody—or the personas that exist within your team—can be a game-changer.

Let’s explore the five common PM personas. This will help you understand where you fit in, and more importantly, how to leverage your strengths (or that of your team) to build products that matter.

1. The Visionary PM

The Visionary PM is the dreamer. They’re often the ones who see the world as it could be, not just as it is. They’re driven by big ideas, and they tend to think in terms of the long-term impact and potential of a product.

• Strengths: They’re great at rallying teams around a shared vision and getting everyone excited about the future. They’re also adept at spotting trends before they become mainstream.

• Weaknesses: The biggest challenge for Visionary PMs is execution. They can get so caught up in the "next big thing" that they struggle with the day-to-day details that make a product successful.

Tip: If you’re a Visionary PM, pair yourself with someone who excels at execution. Your ideas need grounding, and you need someone to help you turn them into reality.

2. The Data-Driven PM

The Data-Driven PM lives and breathes metrics. They believe that every decision should be backed by data, and they often have a dashboard open at all times. This type of PM is excellent at finding insights from user behavior, A/B tests, and market trends.

• Strengths: They make informed decisions based on real-world evidence, which means their strategies are often well-founded. They excel at optimizing products and features based on user feedback and engagement.

• Weaknesses: Data can be limiting. The Data-Driven PM sometimes struggles with taking risks or thinking outside the box because they want every move to be validated by numbers.

Tip: Remember that not everything can (or should) be quantified. If you’re a Data-Driven PM, don’t be afraid to trust your instincts every now and then, especially in areas where data is scarce.

3. The Technical PM

The Technical PM has a background in engineering or computer science. They understand the nuts and bolts of how products are built and often have a deep understanding of the tech stack, APIs, and architecture.

• Strengths: They’re great at communicating with developers, making technical trade-offs, and understanding the complexities of what’s possible. When it comes to building technically challenging features, the Technical PM is in their element.

• Weaknesses: They sometimes get too caught up in the "how" and lose sight of the "why." This can lead to over-engineering solutions or focusing too much on technical details rather than user needs.

Tip: Always ask yourself: "Is this solving a real problem?" It’s easy to get lost in the tech, but at the end of the day, your goal is to build something users love.

4. The User Advocate PM

The User Advocate PM is obsessed with the customer experience. They spend their time talking to users, conducting surveys, and reading every piece of feedback. They’re the champions of empathy and can often be heard saying, "But how will this make our users feel?"

• Strengths: They excel at building products that users love. They have an uncanny ability to understand what users want, even when users themselves can’t articulate it. This makes them particularly strong in crafting user interfaces, onboarding experiences, and product flows.

• Weaknesses: The downside is that they can get too emotionally attached to user feedback, even when it might not align with broader business goals. Sometimes, they prioritize user wants over what’s feasible or profitable.

Tip: Balance empathy with strategy. Your job isn’t just to make users happy; it’s also to help your company grow. Use your empathy as a tool, but don’t let it dictate every decision.

5. The Generalist PM

The Generalist PM is a jack-of-all-trades. They might not have deep expertise in one particular area, but they’re competent across various domains. They’re equally comfortable discussing design, technology, business strategy, and user experience.

• Strengths: They’re incredibly adaptable and can fit into different roles depending on the needs of the team. They’re great at connecting the dots between different departments and ensuring that everyone is moving toward the same goal.

• Weaknesses: The challenge for Generalists is that they can sometimes lack depth in any one area. This makes it harder for them to lead initiatives that require specialized knowledge or skills.

Tip: Focus on developing a “T-shaped” skillset—broad knowledge across multiple areas with deep expertise in at least one. This will make you more valuable and help you stand out from the crowd.

Why Knowing These Personas Matters

As a founder, you need to recognize the different PM personas on your team—or the personas you might be missing. This awareness helps you make better hiring decisions, craft more balanced teams, and understand how to leverage each person’s strengths.

If you’re an aspiring or early-stage product manager, knowing your persona helps you understand where you’ll thrive. It also highlights areas where you might need to grow. For example, if you’re naturally a Visionary PM, it might be worth investing time in understanding data analytics. If you’re a Data-Driven PM, learning more about user experience design could make you a more well-rounded product leader.

The Hybrid PM: The Ideal Blend?

Most experienced PMs eventually develop a hybrid persona, combining traits from different types. You might be a Visionary with strong technical skills or a Data-Driven PM who’s also a User Advocate. This blend makes you versatile and able to tackle different challenges, but it doesn’t happen overnight. It takes deliberate effort, experience, and learning from different projects.

Final Thoughts

Product management isn’t a one-size-fits-all role. The best teams are those that recognize and embrace the different PM personas, using them to complement each other. Whether you’re a founder building a team or a product manager finding your path, understanding these personas will give you the insight to navigate the journey more effectively.

So, which type are you? And more importantly, how will you leverage that to build the next great product?

Let’s get to work.

I want to chat about something that's been on my mind lately: the balance between principles and processes in product development.

As someone who has seen products in large enterprises & now building on my own, I've seen firsthand how easy it is to get bogged down in endless procedures. But what if I told you there's a better way?

The Process Trap

We've all been there. Your team is growing, and suddenly everyone's asking for more structure. Before you know it, you're drowning in spreadsheets, meetings, and fancy frameworks. Sound familiar?

Don't get me wrong – some process is good. It helps newbies find their feet and keeps things running smoothly. But too much of it? That's when the magic starts to fade.

Why Principles Trump Processes

Here's the thing: great products aren't born from rigid rules. They come from creative thinking, quick action, and learning from mistakes. That's where principles come in.

Think of principles as your team's North Star. They guide decisions without dictating every little step. They empower your rock stars while still giving structure to those who need it.

My Top 5 Product Principles

1. Problem First, Features Second: Always start by asking, "What problem are we solving?" Not, "What cool feature can we add?"

2. Think Big, Act Small: Have a grand vision, but tackle it bit by bit. It's like eating an elephant – one bite at a time!

3. Ship It, Then Shape It: Get your product out there fast. It doesn't have to be perfect. Launch, learn, and improve.

4. Trust Your Team: Micromanaging is so last season. Give your team the big picture and let them figure out the details.

5. Data > Gut Feeling: Trust your instincts, but always back them up with cold, hard facts.

Making the Switch

Okay, so you're sold on principles over processes. But how do you actually make this work? Here are some tips:

1. Start Small: Pick a few principles that resonate with your team. Don't try to change everything overnight.

2. Lead by Example: Use these principles in your own decision-making. Your team will follow suit.

3. Celebrate the Wins: When a principle leads to success, shout it from the rooftops! (Or at least in your team meeting.)

4. Be Flexible: Principles should evolve as your team and product grow. Revisit them regularly.

5. Keep It Simple: If you need a 50-page manual to explain your principles, you're doing it wrong.

The Payoff

When you embrace principles over processes, amazing things happen. Your team moves faster. They take more risks (the good kind). They solve problems creatively. And most importantly, they build products that people actually want to use.

Wrapping Up

Look, I get it. Processes feel safe. They're easy to measure and control. But in the fast-paced world of product development, they can be more of a ball and chain than a safety net.

By focusing on solid principles instead, you create an environment where great ideas can flourish. You empower your team to think for themselves and make smart decisions. And at the end of the day, isn't that what great product leadership is all about?

So, what do you think? Are you ready to ditch some of those dusty old processes and embrace the power of principles? I'd love to hear your thoughts!

Until next time, keep innovating and stay awesome!

What are APIs?

APIs have gained recognition as the vital "connective tissue" within digital ecosystems, presenting organizations with boundless integration possibilities and business opportunities when developed and utilized effectively.

An API acts as a bridge between different software systems, enabling them to share and access data or functionality. It provides a standardized way for developers to access the capabilities of a particular software application, such as retrieving data from a database, sending data to another application, or performing specific actions.

APIs can be exposed in different ways, such as REST (Representational State Transfer), SOAP (Simple Object Access Protocol), GraphQL, or gRPC. Each API type has its own conventions and protocols for making requests, handling responses, and exchanging data. However, REST is the most modern way of exposing APIs and are usually referred to as “REST APIs”.

What is API Product Management?

API product management is a specialized role that involves the strategic planning, development, and management of APIs as products. The goal of API Product Management is to ensure the development and eventual launch of successful API products that drive business value, create customer delight, and generate revenue. API Product Managers (PMs) are responsible for overseeing and managing the entire API product lifecycle as well as building a market for end-users. API Product Managers must have a deep understanding of the API market, the needs of their customers, and the capabilities of their organization. They must also be able to effectively communicate with both technical and non-technical audiences.

API Planning

Consider the following key steps when planning an API:

1. Define the Purpose: Clearly articulate the purpose of the API. Determine the problem it aims to solve, the target audience which includes developers or end-users, and the value it will provide to them.

2. Conduct Market Research: Understand the competitive landscape and identify similar existing API solutions. Analyze their strengths, weaknesses, and gaps to position your API effectively. Identify the target market, potential customers, and their specific needs or pain points. (this is just like any other product!)

3. Gather Requirements: Engage with stakeholders, including internal teams, external developers, and end-users, to gather requirements. Identify the key functionalities, security measures, performance expectations, and integration capabilities needed for the API.

4. Create an API Roadmap: Develop a high-level roadmap that outlines the planned features and milestones for the API. Prioritize the features based on customer needs, technical feasibility, and business objectives. Consider the timeline, resource allocation, and dependencies for each feature.

5. Design the API: Define the API architecture, data models, endpoints, and request/response formats. Consider the principles of simplicity, consistency, and scalability in the design. Use industry-standard protocols and practices to ensure compatibility and ease of integration.

6. Security Considerations: Design appropriate security measures for the API and evaluate potential security risks. Consider authentication mechanisms, authorization frameworks, encryption standards, and protection against common vulnerabilities. Ensure compliance with relevant data privacy regulations.

7. Developer Experience: Pay attention to the developer experience by providing clear and comprehensive documentation, sample code, SDKs, and other resources. Reducing friction is the key here - strive for simplicity, ease of use, and intuitive design to facilitate smooth onboarding and integration.

8. Test and Iterate: Develop a testing strategy to ensure the API's functionality, performance, and reliability. Conduct thorough testing, including unit tests, integration tests, and security assessments. Collect feedback from developers and iterate on the API based on their input.

9. Versioning and Lifecycle Management: Since any product will have future updates and enhancements, consider versioning strategies. Define guidelines for versioning, backward compatibility, and deprecation to ensure a smooth transition for existing users as the API evolves.

10. Documentation and Support: API documentation is often ignored. Develop comprehensive and up-to-date documentation that covers all aspects of the API, including usage instructions, reference documentation, troubleshooting guides & FAQs. Provide developer support channels such as forums, ticketing systems, or dedicated support teams to address queries and issues.

11. Release and Adoption: Plan the release of the API, including communication and marketing strategies. Engage with developer communities, organize hackathons or events, and leverage partnerships to drive adoption and foster a vibrant ecosystem around the API.

12. Monitoring and Evaluation: Establish metrics and analytics to monitor the API's usage, performance, and user satisfaction. Continuously evaluate the API's effectiveness in achieving its goals and make data-driven decisions for future enhancements or updates.

Benefits of API-first Mindset

Here is why API-first mindset is beneficial:

1. Do more with less : Companies have welcomed the idea of choosing from a variety of smaller, more specialized tools & products and began assembling collections of individual solutions that best matched their particular needs. API-first mindset allows companies to solve challenges of a specific functional area and do it well rather than solve for a wide variety of organizational challenges.

2. Interoperability : Integrations have become a crucial part of product strategies. And to make integrations seamless, standardization is an important aspect. Standards help to promote compatibility and overall utility between systems. When API products adopt common standards, such as OpenAPI Specification (OAS), it enables consumers to harness the ecosystem of third party tools and systems which are also compatible with those standards. This is the equivalent of ‘network effects’.

3. Modularity & Platform Thinking : For product leaders, developing a successful API strategy requires a mindset shift from product thinking to platform thinking. This means building products in a modular, open-ended fashion that allows their functionality to be recombined and that prioritizes flexibility for developers. The decoupled nature of API-first helps to reduce dependencies and even makes it possible to vary tech stacks across APIs, if required.
   This is also true of the infrastructure required to host the APIs, as each API can choose its own infrastructure, specific to its needs. This fits well with modern deployment approaches, such as containerisation, where individual services are sized as needed, and scaled on demand.

4. Developer Experience : By focusing on the design of APIs and building them with a product mindset, the resulting APIs provide a better developer experience (DX). DX is a foundational pillar of a sound API strategy. Consistency is also important to the overall developer experience. Developers face fewer difficulties in consuming an API when data is provided in common formats, using common protocols and processes. Ultimately, developers are the users who ultimately call/integrate with an API, the potential partners who can help realize a product-to-platform vision

5. Better Security : When implemented with rigor, the products and platforms with REST APIs are more secure than other ones. The APIs provide a layer of abstraction over the written code & systems.

Challenges of API-first Approach

While there are benefits, it is also important to know the challenges in adopting an API first approach:

1. Cultural Shift : Leadership support is critical to develop API products & platforms. API-first approach requires a change in mindset, and to treat APIs as their own products. Without this, APIs will remain a purely tactical play, limited in scope and lacking the necessary strategic thinking. Leadership support is needed to ensure that any necessary changes in process, people and culture have the required level of support to succeed.

2. Freedom of Choice in Tech Stack : While APIs allow freedom to choose a different stack for each API product, it also means that a broader skilled workforce is required for the company. Therefore, an organisation’s hiring decisions will affect the flexibility and cost of the workforce, as well as the development time and overall quality of the outcomes.

3. Governance of Standards : Without adequate governance, the whole API-first concept is undermined. As with any scenario where one system consumes the output of another, it’s important that the consumer can rely on the other system. Otherwise the integrations between consumers and providers will be fragile and subject to failure when any change occurs, which is bound to happen. This means that it’s important to adopt a robust release process and approach to versioning, as well as clear policies on backwards compatibility.

4. Security & Attacks : While APIs are secure, but they need to be available over the internet for consumption by consumer products. In addition, as the number of APIs increases, so does the attack surface. Of course, there are many measures which mitigate the threats posed to APIs, but companies must be aware of them and take appropriate action. Rate limitation is one such method.

To summarize, a successful API strategy isn’t just about building products, it’s about building capability. An API product manager must adopt a platform mindset and prioritize the factors that will smooth adoption for the potential partners who can then take their API, integrate, and run with it.

Let's say, you're planning to launch a new feature or product. You may be a product manager, or anyone building technology products, or even someone in the business leading a feature launch. This article answers the key 5 questions around this thought.

What is a Press Release?

This short & crisp document (typically one to one and half pages) is a desirable future communication that you would like to "announce" in the team/organization about the launch of the feature or product. It is more like an org-wide announcement of what you have released and is written from a future point-of-view when this feature or product will be released. This concept was popularized by Amazon.

It is important to note that this Press Release (referred as PR in this article), is not the same as one used by marketing to share with media. Although, this document can serve as an input for the marketing team, and will be highly useful in designing public campaigns.

How does a Press Release help?

The PR is

• simple enough to be understood by anyone in the organization

• short & crisp to be read & understood by everyone

• focussed on delivered outcomes & benefits

Why should we write the Press Release before building the feature/product?

This is the important part. Writing a PR before you start building the product forces us to start from where the customer starts thinking. Ultimately, you want to deliver value to the customer, so it's good to start from there. Then you can work backwards and build only what relates to this.

What is a simple & minimal PR format?

Heading : short name for the product/feature that the customer will understand

Subtitle: One sentence saying who the market is and what the benefit is

Summary: 2–4 sentences that gives a summary of the product and the benefits. Should be self-contained so that a person could read only this paragraph and still understand the new product/feature.

Problem : 2–4 sentences describing the problem that a customer faces, which this product solves. Tests your assumptions about the pain-points that you are addressing.

Solution : 2–4 sentences, describing how the new product/feature addresses this problem. Tests your assumptions about how you are solving the pain-points.

Getting started: 1–3 sentences describing how someone can start using this product/feature (if it’s baked into the existing product, say this explicitly). Tests your assumptions about how easy the ramp-up is for your customers to take advantage of the new product/feature.

Internal quote: Someone within your company being quoted about what they like about the product/feature. Tests your assumptions about the value you are creating for your customers and how you position this product within your broader product offerings.

Customer Quote(s): a hypothetical customer saying what they like about the new product/feature. Tests your assumptions about how you want your customers to react to the new product/feature and your ideal customer profile. They should be doing something that they couldn’t do before, doing something much quicker and easier, saving time and effort, or in some other way making their life better. Whatever the benefit is, their delight in the benefit(s) should be exhibited in the quote. This should be multiple quotes from different customers if you have multiple profiles of ideal customers, example: mid-market and F50 customers.

Call to action: 1–2 sentences telling the reader where they can go next to start using the product/feature. Tests your assumptions about whether this is a feature that is automatically on, something they need to turn on, a beta-release, etc.

Source : PR Format

Note : You may consider to subscribe to ProductCirqle, where I share my thoughts, tools & frameworks on product management.

I came to realize a pattern on how PMs operate - learning largely on my own experiences and from the peers I have worked with. Out of the many things we do, the core thing that we always are up to is - form a hypothesis, make assumptions & see what drives business & growth. To do this effectively & to navigate through the uncertainty, the PM needs to ask the right questions to deliver high impact.

So, there are 3 key questions that I have identified, we need to constantly ask for each product we build

1. Do people need this product?

This is typically a starting question for new product development. It is the most fundamental question a PM must raise, ask & answer, if there is to be even a remote chance of a small success. The answer to this question leads to a product-market fit.

2. Will the product be profitable? Or has the potential to be profitable?

A starting sequence to this question is - will people pay for this product/service? If they pay, how are the unit economics going to work? Can the business generate profit from this product? If not now, then when? These questions help you to satisfy the business-side stakeholders of your role.

3. Can we execute this?

Typically, most products can be built. The question leads us more towards the feasibility assessment with the current team that you have and also if you need to invest more on the resources (eg hiring, infrastructure, etc). To identify this, you must work closely with engineering to understand how they plan to implement this - if they are not missing on any of your requirements.

While we answer the above questions, an important job is to communicate the answers that you are finding to everyone on the team. To me, this is an important piece on top of the 3 questions you must ask.

Cheers!

Note : You may consider to subscribe to ProductCirqle, where I share my thoughts, tools & frameworks on product management.

Blockchain platforms consist of a variety of features, which allows the enterprises to select the appropriate feature for different kinds of capabilities based on the application of this technology.

According to me, these four key features are critically important when evaluating blockchain platforms, their components & its application:

1. Whether a platform is open (that is, a public blockchain) or closed (a private blockchain) and how that affects speed and security. This mainly depends on the use case being executed, which defines whether you want a public or private Blockchain. Anyone can join a public blockchain, which can make it easier to set up for small-business users. The downside is that open blockchains are not as fast. Many of the blockchain code bases can be modified to be either open or closed. Private Blockchains allow only restricted participants and are faster in execution speeds.

2. Consensus mechanism, such as PoW, PoS or Byzantine fault tolerance. This is a core principle of Blockchain, which simply means that when data is recorded on Blockchain, it must be agreed to by all the participants of the Blockchain or participants who are authorized to validate the transaction data. This ensures that the participants can trust the data on the Blockchain. There are multiple consensus mechanisms and every Blockchain may use a different consensus algorithm, depending on the type of Blockchain and how the data is validated & written in the Blockchain**.** PoW is the older mechanism used in Bitcoin and Ethereum. The others are newer and less proven but faster and more efficient.

3. Ledger technology and how it records the transactions. This relates to how the blockchain keeps track of information. Popular approaches include an account model and UTXO. An account model records the balance, whereas the UTXO model is analogous to cash with serial numbers in your wallet. The account model is used in the blockchain platforms Ethereum, Stellar, Tron and EOSIO. IBM Blockchain, Hyperledger Fabric and Hyperledger Sawtooth use UTXO.

4. Intended smart contract functions for capturing business logic on the blockchain. Smart contracts are coded version of business logic, which can be trusted. Many blockchain platforms enable smart contracts. Reduction in payment reconciliation time and cost is the most important advantage of smart contracts in supply chain use-cases. Additionally, transactions which are sent from unauthorised agents, or in a wrong point of the process, can be automatically rejected, which prevents double-spending and human mistakes. Smart contracts Popular programming languages include Ethereum Solidity, WebAssembly languages and Digital Asset Modeling Language.

This article is also published here.

Blockchain is a transformative technology, which has re-imagined business models based on trust, giving a sustainable competitive advantage and reducing time, costs & risks. In addition to the basic properties of Blockchain, there are a few properties - which makes it important & usable for businesses.

Privacy

Enterprise Blockchains use various kinds of techniques to ensure privacy as it is a critically important aspect to businesses. With Blockchain, businesses from the same or different industry may come together to execute a particular use-case on Blockchain, it is important that the competitors do not know each others’ business-sensitive information. For this reason, enterprise Blockchains use secure private channels, zero-knowledge proofs & many other techniques to achieve the same.

Higher Performance & Scalability

The ability to process transactions in huge volumes is important for businesses, for any real world scenarios. Many enterprises current performance requirements are much greater than what enterprise Blockchains can offer. This is restricting these businesses to move from pilot stages to real world scenarios. Businesses are finding work-arounds by designing architecture in such a way that this is handled. With time, and evolution in this space, this problem is being addressed.

Identity & Accountability

Since enterprise Blockchains are permissioned & private - the participating members are restricted & known. Each of these members are identified by digital signatures or cryptographic keys. This ensures accountability of the information recorded on Blockchain or the smart contracts which are executed. Therefore, the identity can always be proved, which is a problem for businesses in public Blockchains.

Incentive

Unlike public Blockchains, which incentivize members with tokens, enterprise Blockchains do not reward members with crypto-tokens or cryptocurrencies. The incentive is more business driven which is a realized benefit due to the implementation of Blockchain - like cost savings. Another emerging incentive, which may be used by enterprises is ‘asset tokenization’.

Governance

This aspect of an enterprise Blockchain removes the uncertainties & risks associated with bringing multiple stakeholders together. This encourages participation & unlocks new business models. A smart contract helps to achieve this, where the governance is ensured in a decentralized fashion so that there is a consensus on the business agreement & the way it will be executed. This can also achieved by the technical design & architecture of the solution.

The above factors provide an unmatched benefit to enterprises, to consider implementing Blockchain solutions, which are not public Blockchains & can deliver meaningful business returns.

This article is also published here.

Digitization of money has evolved in various forms over the last few years. It has completely revolutionized money and the payment systems, and yet has a lot of scope for disruption. While digital money itself is not new to modern economies, the ability to transfer money instantaneously, peer-to-peer has opened up opportunities and efficiencies. This will and has lead to emergence of new currencies which transcend national borders, redefining the ways in which people use & interact with money & make payments. The emergence of these new methods have a strong potential to reshape the international monetary system and the role of government-issued public money.

The first important economic insight is that digital currencies feature innovations that will unbundle the functions served by money (store of value, medium of exchange, and unit of account), rendering the competition among currencies much fiercer. Digital currencies may specialize to certain roles and compete exclusively as exchange media or exclusively as stores of value.

Secondly, a social impact will be the attempt by digital money issuers to “differentiate” their currency by re-bundling monetary functions of their currency with traditionally separate functions, such as data collection and social networking services (like Libra from Facebook). The ability of these currencies to convert & exchange across different platforms will help exploit the benefits to its maximum effect. The importance of digital connectedness, which often supersedes the importance of macroeconomic links, will lead to the establishment of “Digital Currency Areas” (DCAs) linking the currency to usership of a particular digital network rather than to a specific country. The border-defiant nature of these digital currencies will make both emerging and advanced economies vulnerable to their national currency being replaced by a digital platform’s currency rather than a fiat currency or another developed country’s currency.

Third, in a digital currency, cash may effectively disappear, and payments may center around social and economic platforms rather than banks’ credit provisioning capabilities, weakening the traditional distribution channels of monetary policy. Governments may need to offer central bank digital currency (CBDC) in order to retain the monetary independence - a compulsive thought provoked by cryptocurrencies.

This article is also published here.

Photo by Paul Loh: https://www.pexels.com/photo/worm-s-eye-view-architectural-photography-of-high-rise-building-233698/

Blockchain began with decentralizing the financial sector and is now well positioned to solve some inherent problems that existed in the traditional systems of businesses and corporates. While different Blockchains have different capabilities - scalability, decentralization, security, etc, let us have a look at the top 3 platforms for enterprise Blockchain applications:

1) Hyperledger Fabric

Hyperledger Fabric is an open-source, permissioned distributed ledger technology (DLT) platform, designed for enterprise use. It is a part of the larger Hyperledger project and is backed by large enterprises such as IBM. Hyperledger Fabric has a modular design & can be used for complex use cases. It is a permissioned Blockchain system and not a public Blockchain. While the basics of Blockchain remain intact, the platform supports private channels of communication between network participants, allowing for enterprises to prevent anyone to access this data. Therefore, it allows for higher transaction speeds. It does not have a native cryptocurrency (as most business cases might not require) and has the ability to use smart contracts (they call it as 'chaincode').

2) R3 Corda

R3 was launched in 2015 and currently comprises of world’s largest financial institutions that has created an open-source distributed ledger platform known as Corda. Now, this platform comes in two versions — Corda open-source and Corda Enterprise. Although Corda was originally built to serve banking industry, recent use of Corda in sectors such as supply chain, healthcare, trade finance and government is now emerging. Corda has neither built-in token nor cryptocurrency, but it is a permissioned blockchain because Corda limits access to data within an agreement to only those permissioned, but not to everyone in the entire network - on "need to know" basis. Corda’s consensus system can handle the complex financial agreements. Corda development can be done in Java or Kotlin and the resources in these languages are easily available.

3) Ethereum

Ethereum is an open-source and permissionless blockchain platform that lets anyone build and use decentralized applications that run on blockchain technology. It is designed for mass consumption versus restricted access (typically a requirement in enterprise use-cases). Ethereum is known for its smart contract functionality and flexibility, it is used widely across multiple industry use cases, and it has the largest number of use-cases available today. While network scalability is one of the key advantages of Ethereum, the high gas fee is a disadvantage.

Between the available platforms for enterprise blockchain applications, there isn’t much of a difference. Rather, businesses must select the appropriate platform based on their requirements. In the end, it comes down to the goal and purpose of considering Blockchain for the use case.

Over the past few years, enterprise blockchains have gone from being just an exciting technology with some potential, to a technology that has started to provide immense value to enterprises. These enterprises have moved from POCs, pilots & experiments to using Blockchain in at least some of the internal use cases & processes. Some have even deployed it for commercial use cases.

Based on what I feel could be the key areas to watch, I am sharing the top 5 application trends. Since this area is highly dynamic, this list might look outdated after a couple of months. It is also a non-exhaustive list.

1) Metaverse

An integration of the physical & virtual worlds

With the social media giant Facebook, rebranding itself as 'Meta', it has taken a huge & calculative bet. We will see a lot more innovation & commercialization of use-cases around metaverse. While virtual games & worlds existed earlier, in the coming times, we could see the businesses offering integrated experiences between the physical & virtual worlds, driving commerce & other monetization streams. The ability to maintain private identities, the privacy of avatar actions, and the ability to make and receive payments, among others will be the key drivers for metaverse applications on Blockchains.

2) NFTs

Driving customer engagement

NFTs are assets on Blockchain which are rare & unique - which drives attractiveness for the buyer. They record publicly verifiable ownerships of physical & digital assets on Blockchain. In this and the next year, we could see a shift of NFTs being used just as an exclusive limited-edition asset to be integrated tightly with business processes like rights management. I could find a useful example - VeeFriends are NFTs issued by Gary Vaynerchuck with built in benefits, just like a digital pass.

3) DeFi & DAO

DeFi or Decentralized Finance has gained traction with many Blockchains now supporting faster throughputs & cheaper transactions. Globally, in 2022, we could see businesses identifying the risks & working out mitigation strategies around it with the regulators to make the initiator traceable - full transparency & anonymity being the biggest challenges for businesses & governments. We are also seeing DAOs or Decentralized Autonomous Organizations, emerging as governance mechanisms. DAOs may also open up the way for regulators to be part of the disclosure and transparency solutions that are put in place. Enterprise and DLT blockchain can likely be the vehicles for that collaboration.

4) Industry Collaborations on Supply Chain & Finance

As more & more businesses have started using Blockchains for internal processes, they will look to connect this with the external ecosystems as well. This would bring interoperability & cross-platform capabilities into the light. These sort of integrations will solve some key problems for the businesses - data reconciliation & business data privacy. I see that this kind of an effort will most likely start from supply chain and financial use cases.

5) Tokenization

Tokenization of business assets & processes will help businesses solve problems across multiple areas. An asset will become a token on the Blockchain and then can help tackle fraud and counterfeiting (for luxury goods or other use cases), reduce counterparty risks, improve settlement efficiencies, reduce reconciliation, and improve overall liquidity. One such example is from Goldman Sachs.

It’s important to note that these trends are also interconnected. Visionary enterprises will look to explore how enterprise blockchain technology will interlink with the innovations on the public blockchain. As ecosystems expand, interoperability needs will begin to strongly exert themselves in order to meet evolving customer expectations. The benefits of blockchain technology are just too great to ignore for future business and tech innovation. 

Find more on my website