7. Evaluating Startup Ideas

An idea is not evaluated by how impressive it sounds in a pitch. It is evaluated by whether a real customer has a painful problem, whether someone can pay for a solution, whether the market gives you room to enter, whether you have a learning advantage, and whether the business can become attractive if the early wedge works.

The core idea-evaluation question is: what must be true for this idea to become a real business, and what evidence do we have today for each part of that belief?

Most founders over-evaluate the idea sentence and under-evaluate the situation around the idea. “AI tool for small businesses” is a sentence. “Restaurant owners in Pune lose two hours daily reconciling UPI payments, aggregator payouts, refunds, and GST invoices, and the owner currently does it manually on Sunday night” is a situation. Situations can be tested. Sentences mostly create debate.

The Evaluation Rule

A startup idea is promising when five things are true enough to investigate:

• The pain is frequent, intense, costly, urgent, or risky.
• The buyer is identifiable and has a reason to act.
• The market is reachable from where you are starting.
• The founder has an advantage in learning, access, speed, or execution.
• The business can produce repeatable revenue without heroic effort forever.

You do not need perfect answers on day one. You need enough evidence to decide the next test. Evaluation should reduce uncertainty, not create a beautiful document that delays contact with customers.

1. Pain

Pain is the center of the idea. Weak pain creates weak sales, weak retention, weak pricing, and endless feature requests.

Evaluate pain across five dimensions:

Dimension	What to look for
Frequency	Does the problem happen daily, weekly, monthly, or only rarely?
Intensity	Does it make the customer angry, anxious, embarrassed, or stuck?
Cost	Does it waste time, money, revenue, reputation, or compliance safety?
Urgency	Does someone need to solve it now, or can they ignore it for another year?
Visibility	Is the problem visible to the person with authority, or hidden inside the team?

The best early ideas usually combine frequency with cost. A monthly problem can still matter if the consequence is severe, such as payroll errors, failed compliance, revenue leakage, or customer churn. A daily problem can still be weak if people have learned to tolerate it and no one owns the cost.

Ask customers:

• What happens when this problem occurs?
• Who notices?
• What does it cost in time, money, lost customers, or risk?
• What do you do today?
• When did you last try to fix it?
• What made that attempt fail?

If the customer cannot remember the last time the problem happened, it is probably not urgent enough. If they can tell the story with names, dates, workarounds, and frustration, keep digging.

2. Buyer

For many Indian founders, the first serious mistake is confusing the user with the buyer. The user may love the product. The buyer may not care. Or the founder may pitch to a junior team member who feels the pain but cannot move budget.

Map the buying system:

Role	Question
User	Who lives with the problem daily?
Buyer	Who owns the budget or payment decision?
Approver	Who can say yes even if they do not use it?
Blocker	Who can stop the purchase because of risk, process, politics, IT, finance, or compliance?
Beneficiary	Who gets a better outcome if this works?
Blamed owner	Who gets blamed when the problem continues?

The blamed owner is often the most useful person to understand. In B2B, budget follows blame. If the head of sales is blamed for missed targets, a revenue tool has a path. If the operations manager is blamed for delays, workflow software has a path. If everyone complains but nobody is accountable, selling becomes slow.

For consumer products, replace budget with attention, habit, trust, and willingness to pay. A consumer may have pain but no willingness to switch, share data, change routine, or pay.

3. Market

Market size matters, but early founders misuse it. A huge TAM does not help if you cannot reach the first hundred customers. A small wedge can be excellent if it is reachable, painful, and expands into adjacent workflows.

Evaluate the market through operating questions:

• Are customers already spending money on this problem?
• Are they spending with software, people, agencies, consultants, manual labor, or internal teams?
• Is the market growing, fragmenting, formalizing, digitizing, or being forced to change by regulation?
• Are current solutions hated, too expensive, too complex, or not built for this segment?
• Can you reach buyers through a channel you understand?
• Does the customer have a reason to switch now?
• Is there a path from a small wedge to a larger workflow or market?

Competition is not automatically bad. No competition can mean you are early, but it can also mean there is no budget. Existing spend is often a good sign. Your question is not “Is anyone doing this?” Your question is “What is still badly solved for a specific segment, and why can we enter there?“

4. Founder Advantage

Founder advantage is not a vanity point. It is the reason you can learn faster than the market expects.

Good advantages include:

• Domain expertise from working inside the problem.
• Customer access through your job, network, community, or previous company.
• Technical ability to build something others cannot easily build.
• Distribution access through content, partnerships, sales skill, geography, or reputation.
• Speed from a small team that can test quickly.
• A non-obvious insight about why existing solutions fail.
• Credibility with the buyer because you understand their world.

Be honest about fake advantages. “I am passionate” is not enough. “I know this industry” is not enough if you cannot reach buyers. “We can build it” is not enough if distribution is the hard part.

The strongest founder advantage often looks boring: you can call twenty buyers this week, you know the workflow deeply, and you understand why current solutions fail in practice.

5. Business Potential

An idea can be painful and still become a poor business. Before building, ask what the business might look like if it works.

Look for:

• Pricing power: customers pay because the pain is expensive.
• Gross margin: delivery does not require too much manual work forever.
• Repeat purchase: the need recurs.
• Expansion potential: one solved workflow opens adjacent workflows.
• Retention: customers keep using it because it becomes part of operations.
• Defensibility: data, workflow ownership, distribution, brand, network effects, or switching cost can compound.
• Payback period: customer acquisition cost can be recovered in a reasonable time.
• Sales complexity: deal size justifies the effort required to sell.

This is where many services-to-product ideas need care. A service can prove pain and willingness to pay, but if every customer needs custom work, the company may remain an agency. That is fine if you want an agency. It is dangerous if you are raising venture money for a scalable product.

The Assumption Stack

Every idea rests on assumptions. Write them explicitly.

Assumption	Example
Customer	”Independent coaching institutes have this problem.”
Pain	”The problem costs them enough to care.”
Buyer	”The owner can approve payment without a long process.”
Workflow	”The solution can fit into existing operations.”
Trust	”They will trust a new startup with this data or task.”
Distribution	”We can reach them through outbound, referrals, accountants, or local networks.”
Price	”They will pay enough for a viable business.”
Retention	”The need repeats after the first use.”
Expansion	”Solving this opens adjacent workflows.”

The most dangerous assumption is not always the most technical one. In India, it is often trust, payment, reachability, or behavior change.

Good Idea, Bad Entry

Many ideas are not wrong. They are entered badly.

Examples:

• Selling a broad finance platform to all SMBs instead of starting with one painful reconciliation workflow.
• Building a marketplace for all local services instead of one urgent service category with supply constraints.
• Creating an AI assistant for all HR teams instead of one high-frequency workflow like interview scheduling, offer follow-up, or payroll query resolution.
• Building for students broadly instead of one exam, one outcome, one price point, and one acquisition channel.

If an idea looks weak, ask whether the problem is bad or whether the wedge is too vague.

India Angle

In India, idea evaluation needs extra skepticism around price, trust, and buying process.

SMBs may have pain but low ability to pay. Enterprises may have budget but slow approvals. Consumers may love convenience but resist subscriptions. Government-linked and regulated sectors may look attractive but punish founders who do not understand procurement, compliance, and relationships. Tier 2 and Tier 3 markets may be large but require local language, local trust, and different distribution economics.

Do not ask, “Will this work in India?” Ask:

• Which India are we talking about: metro enterprise, funded startups, family businesses, traders, students, creators, rural users, doctors, schools, factories?
• Who is trusted in this market today?
• How does money actually move?
• What is the current offline workaround?
• What will make the buyer believe a new company can be trusted?
• Does the customer prefer software, service, financing, distribution, or a bundled outcome?

Price sensitivity is real, but it is not the whole story. Customers often pay for trust, urgency, status, compliance safety, revenue, and convenience. The founder’s job is to know which one matters.

Evaluation Worksheet

Before you move to validation, write one paragraph for each question:

Question	Your answer
Customer	Who exactly has the problem?
Pain	What happens, how often, and what does it cost?
Buyer	Who pays, approves, blocks, and gets blamed?
Market	What existing spend or behavior proves this category exists?
Timing	Why is now better than three years ago?
Advantage	Why can you learn or execute faster than others?
Business	How could this become repeatable revenue?
Risk	What assumption could kill the idea?
Next test	What will you do in the next seven days?

Then mark every answer as:

• Evidence: observed behavior, payment, workflow, interview detail, or data.
• Assumption: plausible but not yet proven.
• Guess: mostly your opinion.

The goal is not to eliminate all uncertainty. The goal is to know which uncertainty matters next.

Evidence Quality Scale

When evaluating ideas, separate evidence by quality. Otherwise a founder can accidentally treat a clever argument as if it were customer proof.

Evidence type	Quality	Example	How much to trust it
Founder opinion	Very low	”I think SMBs need this.”	Use only as a hypothesis.
Second-hand story	Low	”My friend says restaurants struggle with this.”	Investigate, but do not decide from it.
Customer statement	Medium	”This is painful for us.”	Ask for the last occurrence and current workaround.
Customer behavior	High	They show a spreadsheet, process, tool, agency, or manual workaround.	Treat as real evidence of pain.
Buyer engagement	Higher	Buyer discusses budget, timeline, approval, pilot, or internal process.	Treat as evidence of commercial path.
Commitment	Highest	Payment, signed pilot, data access, internal intro, repeated use.	Use to justify building only the scoped wedge.

For every idea, write the best evidence you have and the best evidence you still need. If all evidence sits in the first three rows, do not build yet. Go get behavior.

Idea Pre-Mortem

Before you spend weeks on an idea, write how it might fail. This is not pessimism. It is cheap risk discovery.

Use this prompt:

It is six months later. We worked hard on this idea, but it failed. The most likely reasons were...

Then fill the table:

Failure mode	Early warning sign	Test before building
Pain was not urgent	Customers agree but do not take next steps.	Ask what happens if nothing changes for 6 months.
Buyer was unclear	Users like it but cannot identify budget owner.	Interview buyer, approver, and blocker separately.
Trust was too hard	Customers refuse data, access, or workflow visibility.	Ask what proof, reference, or control would be required.
Distribution was fantasy	You cannot reach qualified prospects repeatedly.	Build a list and run a channel test.
Economics were weak	Delivery takes too much manual time for price.	Run a manual version and track delivery cost.
Market was too broad	Every call describes a different problem.	Narrow by segment, workflow, geography, or trigger.

The pre-mortem should produce tests, not fear. If the top failure mode cannot be tested soon, the idea may still be too vague.

The First Ten Customer Test

Before you build, pitch investors, or design the brand, try to find ten people who match the first customer profile. This is not a large enough sample to prove a market. It is enough to expose whether your idea is still too abstract.

For each person, record:

Field	Why it matters
Why this person qualifies	Prevents random feedback from entering the evidence base.
Last occurrence	Shows whether the problem is recent or theoretical.
Current workaround	Reveals pain, competition, and willingness to act.
Cost	Connects the problem to time, money, risk, revenue, or stress.
Buyer or owner	Shows whether the pain can become a purchase.
Next step offered	Separates interest from movement.

After ten conversations, ask:

• Did at least six people describe a recent occurrence without being led?
• Did at least five people show a current workaround?
• Did at least three people agree to a concrete next step?
• Did you find the same buyer or owner pattern repeatedly?
• Did the idea become narrower, sharper, or more urgent?

If the answer is mostly no, do not hide behind “the market needs education.” First improve the segment, problem, or access path.

The “Why Now” Test

Every idea needs a reason why now is a better time than before. Without it, you may be entering a market where many smart people already failed for structural reasons.

Useful “why now” answers:

• Technology became cheaper, better, or easier to integrate.
• Customer behavior changed, such as UPI, WhatsApp commerce, video learning, remote work, AI adoption, or mobile-first workflows.
• Regulation created new pressure, documentation needs, reporting requirements, or compliance risk.
• A customer segment reached a new scale and old manual processes are breaking.
• Incumbents moved upmarket and left a segment underserved.
• Distribution changed through creators, communities, marketplaces, APIs, or partnerships.
• Data became accessible enough to create a new product experience.

Weak “why now” answers:

• “The market is huge.”
• “AI is hot.”
• “Nobody has built it well.”
• “People are more digital now.”
• “Investors are funding this space.”

Those may be hints, but they are not enough. A strong timing thesis should explain a specific change in cost, behavior, regulation, access, trust, or workflow.

Business Model Reality Check

Ask how the idea could make money before you fall in love with the product.

Business question	What you are testing
Who pays first?	User, buyer, owner, department, parent, student, patient, advertiser, supplier, platform?
Why would they pay now?	Urgency, savings, revenue, compliance, status, convenience, access, safety?
How much could they pay?	Current spend, budget threshold, willingness, outcome value, competitor pricing.
How often do they pay?	One-time, monthly, annual, usage, commission, success fee, transaction fee.
What does delivery cost?	Support, service, onboarding, data cleanup, operations, human review, refunds.
What expands later?	More seats, more workflows, more volume, more departments, more geographies.

This is not about producing a perfect financial model. It is about avoiding ideas where value is real but economics are broken.

For example, a consumer app with high support needs and low willingness to pay may be difficult unless distribution is unusually strong. An SMB workflow tool may work if onboarding is simple and payment is connected to revenue, compliance, or owner time. A deeptech product may need long pilots, grants, or enterprise budgets before product revenue arrives.

The Founder-Market Fit Interview

Evaluate yourself as honestly as you evaluate the market.

Ask:

• Can I get 20 serious customer conversations without begging?
• Do I understand the customer’s language, status games, fears, and constraints?
• Can I stay interested in this problem for five years?
• Do I have credibility with the buyer or a path to earn it?
• Is the hard part product, sales, operations, regulation, capital, or trust?
• Do I or my co-founder have strength in that hard part?
• What unfair learning advantage do we have this month, not someday?

Founder-market fit does not mean you must come from the industry. It means you can learn unusually fast and earn the right to operate in that market.

Common Mistakes

• Treating market size as proof of customer urgency.
• Talking only to friends, founders, and investors instead of buyers.
• Ignoring who owns budget.
• Choosing a customer segment so broad that no sales message is sharp.
• Assuming a US buying motion will work unchanged in India.
• Falling in love with a technology shift before finding a painful workflow.
• Evaluating the upside but not the route to the first ten customers.
• Scoring an idea high because it would impress investors.
• Underestimating distribution because product work feels more controllable.

Idea Evaluation Kill Zones

Some ideas are not bad in theory. They are bad for you right now because one part of the system is too weak.

Use these kill zones to evaluate honestly.

Kill zone	What it looks like	What to do
No painful trigger	Customers agree the problem exists, but cannot name when it becomes urgent.	Find the trigger or change the problem.
User-buyer split	Users like it, but the budget owner does not care.	Interview buyers before building.
Weak reachability	You cannot reach 50 qualified prospects without heroic effort.	Narrow the segment or find a channel.
Low willingness to pay	Pain exists, but current spend and value do not support a business.	Try a cheaper wedge, service model, or different buyer.
Heavy behavior change	Customers must change habits without strong incentive.	Start inside an existing workflow.
Trust barrier too high	The product needs data, money, health, compliance, or reputation trust you cannot earn yet.	Start with a lower-risk workflow or service layer.
Operational burden	Every customer needs custom delivery, training, support, or offline work.	Productize the service or pick a narrower use case.
Distribution fantasy	The plan depends on “going viral,” “SEO later,” or “partnerships” with no proof.	Test acquisition before building.

An idea in a kill zone can still become a company, but only if you know the hard part and have a credible plan for it.

The Entry Wedge Test

A large market is not an entry strategy. Evaluate the first wedge:

Question	Good answer
Who is the first customer?	A role and segment you can name.
What is the first painful workflow?	A repeated situation with current workaround.
What is the first promise?	A narrow outcome that matters now.
What is the first channel?	A way to reach similar customers repeatedly.
What is the first proof?	A demo, manual result, pilot, reference, or measurable saving.
What is the first payment path?	Buyer, price range, approval threshold, invoice process.

If the wedge is weak, the idea will feel broad and exciting but execution will feel foggy. Tighten the wedge until the next week of work is obvious.

The 10x Better Or 10x Easier Test

Customers rarely switch because a product is “nice.” The new solution must be much better or much easier in one meaningful way.

Ask:

• Is it 10x faster for a painful job?
• Is it 10x cheaper for a costly job?
• Is it 10x more trustworthy for a risky job?
• Is it 10x easier to start than existing tools?
• Is it 10x more accessible to an ignored segment?
• Is it 10x more integrated into where work already happens?

If the answer is “a little better dashboard,” be careful. Incremental improvement rarely beats inertia unless the buyer is already unhappy and actively searching.

Idea Risk Map

Every idea has risks. The mistake is treating all risks as equal.

Map the idea across five risk types:

Risk	Question	Strong signal	Weak signal
Problem risk	Is the pain real, repeated, and costly?	Customers describe recent painful events without prompting.	Customers agree in theory but cannot recall a recent case.
Buyer risk	Can someone approve and pay?	A budget owner explains the buying path.	Users like it but no buyer is visible.
Access risk	Can you reach enough similar customers?	You can list 50 prospects and get conversations.	You depend on one friend, one community, or vague referrals.
Solution risk	Can you create a result that beats the workaround?	A manual or prototype test improves a real workflow.	The value exists only in a product demo.
Business risk	Can this become a durable company?	Repeat purchase, retention, expansion, margin, or network effects are plausible.	Every customer looks custom and expensive to serve.

The highest risk should define the next test. If buyer risk is highest, do not build product. Find buyers. If access risk is highest, do not improve features. Test channels. If solution risk is highest, run a manual workflow test before writing code.

Evaluation Interview Pack

Evaluating an idea requires different questions from discovering an idea. You are no longer asking broadly about pain. You are testing the sharpest assumptions.

Use this interview pack:

Assumption	Question
Problem frequency	When did this last happen? How many times this month?
Problem cost	What happens if this is not fixed? Who notices?
Current workaround	Walk me through how you handle it today. What tools, people, and approvals are involved?
Buyer clarity	Who owns this problem? Who would approve a solution?
Budget	Is money already spent on this through tools, people, agencies, or lost time?
Urgency	Why solve this now instead of later?
Switching cost	What would make changing the current process difficult?
Trust	What proof would you need before trying a new solution?
Competition	What have you already tried? Why did it not work?
Commitment	If this were solved credibly, what next step would be reasonable?

Do not ask all questions mechanically. Pick the questions tied to the riskiest assumption. The goal is not to complete a script. The goal is to make the idea harder to fool yourself about.

Market Pull Vs Founder Push

An idea with market pull feels different from an idea that requires founder push.

Signal	Market pull	Founder push
Customer language	Customers describe the pain before you name it.	You explain the pain and they politely agree.
Next step	Customers ask how to continue.	You chase every follow-up.
Budget	Existing spend or owner is visible.	Payment is always “later.”
Referrals	People introduce you to others with the same problem.	Referrals require repeated asking.
Product scope	The first workflow becomes clearer.	The feature list expands after every call.
Timing	There is a trigger or deadline.	The idea is useful “someday.”

Founder push is normal at the start. But after serious discovery, some pull should appear. If there is no pull after 20-30 qualified conversations, either the segment is wrong, the pain is weak, or the message is unclear.

The First Ten Customers Test

Before believing an idea, write how the first ten customers could happen.

Customer number	Source	Why they might trust you	What they would buy/test	Main blocker
1
2
3
4
5
6
7
8
9
10

If you cannot imagine a credible path to ten, the idea may still be good, but your entry strategy is missing. For Indian founders, this exercise also reveals whether trust will come from personal network, domain reputation, city/community proximity, founder-led demos, references, channel partners, or visible proof.

Decision Summary Memo

End evaluation with a one-page memo:

• Customer segment.
• Problem in the customer’s words.
• Current workaround.
• Buyer and approval path.
• Strongest evidence.
• Weakest evidence.
• Main risk.
• Next seven-day test.
• Stop/change rule.

The memo forces clarity. If the idea cannot survive one page of plain language, it is probably not ready for product work.

Idea Diligence Pack Before You Build

Before writing product specs, prepare a small diligence pack. This is not an investor deck. It is a founder tool that protects you from building on top of vague belief.

The pack should contain:

Artifact	What good looks like
Customer list	25 named people or companies in the target segment, not “SMBs” or “students.”
Problem narrative	A plain-language story of the last time the pain happened.
Workflow map	Current steps, tools, people, delays, approvals, and failure points.
Workaround proof	Screenshots, examples, notes, or descriptions of what they do today.
Buyer map	User, champion, buyer, approver, blocker, and finance owner.
Existing spend	Software, services, salaries, agencies, penalties, discounts, leakage, or lost revenue.
Why-now note	What changed in technology, regulation, behavior, cost, competition, or customer expectation.
Entry wedge	The first narrow problem you will solve, not the eventual platform.
Distribution hypothesis	How the first 100 qualified prospects will hear about you.
Kill criteria	Evidence that would make you stop, narrow, or change segment.

If you cannot prepare this pack, the answer is not to build faster. The answer is to observe more, interview better, or narrow the segment.

Risk Tiers

Every idea has risk, but not all risks deserve equal attention. Sort risks into tiers.

Risk tier	Example	What to do
Fatal	No buyer, no budget, no urgency, illegal/unworkable model, no reachable segment.	Test immediately before building.
Severe	Long sales cycle, low trust, high switching cost, messy integrations, weak retention.	Design a narrow wedge or pilot that proves the path.
Manageable	Missing feature, rough UX, imperfect automation, early support burden.	Do not let this delay customer learning.
Later	Brand polish, scale architecture, full admin controls, advanced analytics.	Park until real usage justifies it.

Founders often spend weeks on manageable or later risks because they feel controllable. The hard work is testing fatal and severe risks early.

The Budget Reality Check

Ask this directly, without making the customer uncomfortable:

• How do you solve this today?
• What does that cost you in people, tools, agency fees, lost time, lost revenue, penalties, or discounts?
• Who owns that cost?
• If this improved meaningfully, whose budget would it come from?
• What would be an easy yes price for a pilot?
• What would require approval?
• What would make it not worth paying for?

In India, many problems are real but paid through labor, relationships, or owner time rather than software budgets. That does not make the idea bad. It means the product may need a different packaging: done-for-you service, financing, bundled workflow, usage-based pricing, channel partnership, or a very narrow ROI promise.

False Positive Signals

Some signals feel good but do not mean the idea is strong. Founders need a way to separate encouragement from evidence.

Signal	Why it misleads	Better evidence
People say the idea is interesting	Politeness is cheap.	Recent painful behavior and willingness to take a specific next step.
Market size is large	Large markets contain many bad wedges.	A reachable segment with a specific urgent problem.
Competitors raised money	Funding proves investor interest, not your wedge.	Customer pain, distribution access, and differentiated insight.
Founder has a clever product concept	Cleverness can distract from buyer urgency.	Customers already spend time, money, reputation, or headcount on the problem.
Friends want to try it	Friends are often biased and forgiving.	Non-friends share artifacts, introduce buyers, or pay.
AI can automate it	Automation does not guarantee trust, budget, or adoption.	A workflow where automation removes a visible cost, delay, risk, or bottleneck.
The product could be used by everyone	Broad usage usually hides weak positioning.	A narrow first user who knows exactly why they need it.
A customer asks for many features	Feature requests can be curiosity, not urgency.	Customer agrees to pilot, pay, share data, introduce stakeholders, or change workflow.

The founder’s job is to move from exciting possibility to painful specificity.

Idea Decision Review

Before moving from idea evaluation to product work, run a short decision review with yourself, co-founders, advisors, or a trusted founder friend.

Use these questions:

Question	Strong answer	Weak answer
Who is the first customer?	Named segment, role, size, trigger, and reachable list.	”SMBs”, “students”, “creators”, “enterprises”, or “everyone.”
What happened recently?	Multiple recent examples of the pain.	General complaint or trend.
What do they do today?	Specific workaround with people, tools, time, and cost.	”They have no solution.”
Who pays?	Buyer, budget source, and approval path are visible.	User likes it but buyer is unknown.
Why now?	Trigger, deadline, cost increase, regulation, behavior shift, or technology change.	”The market is growing.”
Why you?	Access, insight, skill, credibility, distribution, or obsession.	”We can build it.”
What is the next proof step?	Interview batch, artifact review, landing page, prototype, paid pilot, LOI, or concierge test.	Build full product.

End with one of five decisions:

Decision	Meaning
Continue	Evidence is strong enough to keep testing this idea.
Narrow	The idea is real but the customer, use case, or promise is too broad.
Prototype	Customer behavior is strong enough to show a rough workflow or demo.
Paid test	Buyer urgency is strong enough to ask for money, deposit, LOI, or paid pilot.
Kill or park	Evidence is weak, access is poor, or founder advantage is not enough.

Killing an idea is not failure. It is saved time. A founder who can kill weak ideas quickly gives strong ideas more oxygen.

Evaluation Evidence Packet

Before you commit serious build time, create an evidence packet for the idea. This is not a pitch deck. It is a founder’s private truth file.

The packet should fit in a short document:

Section	What to include	Weak version	Strong version
Customer	First segment, role, size, geography, and trigger.	”SMBs in India."	"Owner-led D2C brands doing 500 to 3,000 orders a month with high RTO pain.”
Problem	Specific workflow breakdown and when it happens.	”Operations are inefficient."	"Every Monday the ops lead reconciles courier remittances against Shopify and bank entries.”
Current workaround	Tools, people, agencies, spreadsheets, WhatsApp groups, manual checks.	”They do it manually."	"One junior ops person spends 6 hours a week in a Google Sheet and escalates mismatches to the founder.”
Cost	Time, money, revenue leakage, penalty, risk, churn, founder attention.	”It wastes time."	"Mismatch delays collections, creates founder review work, and hides 1 to 2 percent leakage.”
Buyer	Budget owner, approval path, urgency owner, and blocker.	”The company will pay."	"Founder approves tools below Rs X if ops lead can prove weekly savings.”
Evidence	Interview notes, artifacts, willingness to share data, pilots, deposits, referrals.	”People liked it."	"Four founders shared spreadsheets, two asked for a pilot, one agreed to pay for a manual audit.”
Alternative	Why existing tools, agencies, or internal hires do not solve it well.	”Competitors are bad."	"Existing tools show dashboard data but do not reconcile exceptions across courier reports and bank settlement.”
Next proof	The smallest test that changes the decision.	”Build MVP."	"Run a paid manual reconciliation for three brands and measure leakage, time saved, and repeat demand.”

If the evidence packet feels embarrassing to write, that is useful. It shows which parts of the idea are still living in your imagination.

Evidence Rules

Use these rules while filling the packet:

• Separate what customers did from what customers said.
• Separate user pain from buyer urgency.
• Separate one customer’s custom need from a repeating segment pattern.
• Separate your founder belief from evidence collected after the idea existed.
• Keep exact customer language where possible.
• Link every major claim to a call note, artifact, email, invoice, data point, or next-step commitment.

The evidence packet should make the idea smaller, clearer, and more uncomfortable. That discomfort is not a bad sign. It is the feeling of replacing vague ambition with operating truth.

Idea Risk Burn-Down Plan

Every idea has risks. The mistake is treating all risks equally. A founder should burn down the risks that can kill the company before spending months polishing risks that only matter later.

Classify each risk:

Risk level	Meaning	Example	Next move
Fatal	If false, the idea should stop or radically change.	Buyer will not pay, customer cannot be reached, problem is not painful.	Test immediately with direct customer evidence.
Severe	If unresolved, the idea can move but will be fragile.	Sales cycle is too slow, data access is hard, implementation is custom.	Run a focused sprint before building core product.
Manageable	It matters, but founders can learn while moving.	Pricing page, onboarding copy, first dashboard design.	Decide lightly and improve with usage.
Later	Real issue, but not needed for current proof.	Enterprise security review, large-scale infra, international expansion.	Write it down and ignore for now.

Examples of cheap burn-down tests:

Risk	Cheap test
Customer does not care enough	Ask for a second call with an artifact or stakeholder.
Buyer will not pay	Quote a pilot price and ask what approval would be needed.
Problem is too custom	Compare five artifacts from similar customers.
Distribution is weak	Try to book 10 calls without paid ads or warm investor intros.
Trust barrier is high	Ask for read-only data, sample data, or a controlled pilot.
ROI is vague	Run a manual service and calculate before-after cost.
Founder advantage is weak	Ask why this customer would trust you over a known vendor.

A useful evaluation process does not prove that the idea is perfect. It proves that the next week of work is worth doing.

Buyer-Risk Evaluation

Many ideas look strong until the buyer map is inspected. The person who feels pain, the person who pays, and the person who can block adoption may be different. Evaluate buyer risk before building.

Buyer risk	What it sounds like	Test
User-only enthusiasm	”My team would love this.”	Ask who approves tools, budget, data access, or process change.
Invisible budget	”This is useful, but we do not have a line item.”	Ask what they currently spend to solve or tolerate the problem.
Split ownership	”Operations needs it, finance approves it, IT blocks it.”	Interview each stakeholder separately before product work.
Founder-owner bottleneck	”The owner decides everything.”	Test whether owner feels the pain or only delegates it.
Procurement delay	”Looks good, but vendor onboarding takes months.”	Ask for exact approval steps, documents, and timeline.
Trust-heavy adoption	”We need to know you can handle this safely.”	Ask what proof, reference, pilot, data control, or contract makes trial safe.
Low-status problem	”Everyone complains, but nobody gets rewarded for fixing it.”	Find the blamed owner or choose another wedge.

Use this buyer-risk sentence:

The user is [role], the buyer is [role], the blocker is [role], and the person who gets blamed if this stays broken is [role].

If you cannot fill the sentence, do not assume the product will “sell itself.” Buyer confusion becomes pricing confusion, sales confusion, roadmap confusion, and fundraising confusion.

For Indian B2B ideas, include paperwork and payment reality in buyer risk: GST invoices, TDS expectations, purchase orders, vendor registration, security review, promoter approval, and delayed collections can all change the attractiveness of a seemingly good idea.

One-Week Idea Evaluation Sprint

Do not evaluate an idea for three months in private. Give it one intense week. At the end of the week, you should know whether to continue, narrow, prototype, run a paid test, or park the idea.

The sprint has one rule: every day must produce evidence, not just thinking.

Day 1: Define The Sharp Version

Write the idea in this format:

For [specific customer], who struggles with [specific repeated problem],
we help them achieve [specific outcome] by [first wedge],
starting with [reachable channel or first customer source].

Bad version:

AI for SMB finance.

Better version:

For owner-led D2C brands doing 500 to 3,000 orders a month,
who struggle to reconcile marketplace payouts, courier remittances, refunds, and bank entries,
we help them find leakage and close books faster,
starting with a manual reconciliation audit sold through founder referrals and D2C operator communities.

Then list 25 named prospects. If you cannot list 25, the idea is not yet reachable enough.

Day 2: Map The Workflow

Interview or observe 3 to 5 people. Your goal is not to pitch. Your goal is to understand the current workflow.

Capture:

Item	What to capture
Trigger	When does the problem start?
Current steps	What exactly happens today?
Tools	Spreadsheets, WhatsApp, email, software, agencies, people.
Handoffs	Who gives work to whom?
Failure points	Where do delays, mistakes, leakage, or frustration appear?
Cost	Time, money, lost revenue, risk, reputation, stress.
Owner	Who gets blamed if this stays broken?

If customers describe different workflows every time, narrow the segment. A startup needs a repeatable pattern before it needs a product roadmap.

Day 3: Find The Buyer

Talk to the person who can approve budget, data access, or process change. If you only speak to users, you may end the week with a loved product and no business.

Ask:

• Who owns this problem?
• Who would approve a solution?
• What would make this worth paying for?
• What budget would this come from?
• What paperwork, approval, security, or vendor process would be required?
• What would make you reject this even if users liked it?

For founder-led Indian companies, the buyer may be the promoter, founder, CXO, finance head, or business owner. For larger companies, the economic buyer may be separate from the daily user. Find both.

Day 4: Test Reachability

An idea is not attractive if you cannot repeatedly reach the right customers.

Run a small channel test:

Channel	Test
Warm network	Ask for 10 intros to the exact segment, not general feedback.
LinkedIn outbound	Send 30 specific messages tied to the workflow pain.
Founder communities	Post a concrete problem question, not a product pitch.
Operator communities	Ask for examples of the workflow breaking.
Partners	Ask accountants, agencies, consultants, or software implementers if they see the problem repeatedly.
Content	Publish one sharp teardown of the problem and see who responds.

Measure replies from qualified people, not likes. Likes are not distribution. Conversations with the right people are distribution evidence.

Day 5: Ask For A Commitment

Move beyond compliments. Ask for one reasonable commitment based on the stage of the idea:

Stage	Commitment to ask for
Early discovery	A second call with a stakeholder or artifact.
Workflow proof	A real spreadsheet, report, screenshot, sample data, or process walkthrough.
Buyer proof	A budget conversation, approval-path explanation, or pilot discussion.
Trust proof	Permission to run a controlled manual test on limited data.
Commercial proof	Deposit, paid audit, paid pilot, LOI, or written internal next step.

If everyone says the idea is useful but nobody commits anything, treat that as weak evidence. Do not punish the idea immediately, but do not build yet.

Day 6: Write The Truth Memo

Write one page with uncomfortable honesty:

Question	Answer
What is the sharpest customer segment?
What is the repeated pain?
What did customers show, not just say?
Who is the buyer?
What is the strongest evidence?
What is still a guess?
What is the main kill risk?
What is the next smallest test?

Do not write this memo like a pitch deck. Write it like a founder talking to himself before spending six months of life.

Day 7: Decide

End the week with one decision:

Decision	Meaning	Next week
Continue	Evidence improved and the next risk is clear.	Run the next validation sprint.
Narrow	Pain exists, but the segment or promise is too broad.	Rewrite the customer, workflow, and promise.
Prototype	Customers showed enough workflow pain to react to a rough solution.	Build only the smallest artifact needed for learning.
Paid test	Buyer urgency is strong enough to test money.	Sell a paid audit, pilot, concierge workflow, or deposit.
Park	The idea is interesting but access, timing, or founder fit is weak.	Store the memo and move to a better idea.
Kill	Evidence contradicts the core belief.	Stop active work and write what you learned.

A good evaluation sprint often makes the idea smaller. That is progress. Smaller ideas are easier to sell, easier to build, easier to test, and easier to expand from if the pain is real.

Reader Action

Take your best idea and fill the evaluation worksheet in plain language. Then mark every answer as evidence, assumption, or guess. Your next step is not to improve the idea in your head. It is to turn the most dangerous guess into a customer conversation or a small validation test.

If you are unsure which assumption is most dangerous, choose buyer clarity or reachability. Most early ideas die there.

Related Links

• 6. Finding Startup Ideas
• 8. Idea Scoring
• 9. Idea Validation
• 145. Idea Templates