Skip to content

[Product Discovery] Customer Discovery B2B — 5 Stellar Ecosystem Products #7 #30

Description

@respp

⚠️ This is a PRODUCT and DISCOVERY issue, not a technical one. No code required. What's needed is curiosity, research skills, and the ability to communicate. The responses you collect will directly shape the product roadmap.


Step 0 — Understand the product first

Before contacting anyone, read the Slice documentation. Focus on the dispute resolution section:

https://docs.justly.one

In this order:

  1. https://docs.justly.one/overview/what-is-justly
  2. https://docs.justly.one/overview/dispute-resolution-matters
  3. https://docs.justly.one/use-cases/overview
  4. https://docs.justly.one/how-it-works/dispute-lifecycle

There's also a more detailed B2B product overview inside the repo: docs/product/b2b-overview.md

Don't move forward until you can answer this in one sentence: what problem does Slice solve, and for whom?


The goal

Identify 5 projects in the Stellar ecosystem that likely need dispute resolution, contact someone from their team via text (DM, Discord, Telegram, website contact form), ask them the questions below, and document the responses in research/.

These responses directly feed into Slice's product decisions.


Step 1 — Find your 5 products

Research the Stellar ecosystem using these two sources:

A product is a valid candidate if it meets at least 2 of these criteria:

  • There are two parties exchanging value with each other (buyer/seller, client/freelancer, donor/project, etc.)
  • Funds are transferred based on the fulfillment of something (delivery, milestone, work, claim)
  • The parties may be strangers to each other
  • There is a real incentive for one party to act in bad faith (not delivering, withholding funds, inflating a claim)

Immediately discard any project that:

  • Is in pre-launch development with no real users yet
  • Has not processed any real transactions between users
  • Only exists as a landing page, idea, or prototype without active usage

If a project has never encountered the dispute resolution problem because it doesn't have real users yet, it won't give us useful information. To verify a project is active, look for: recent activity on their social channels (last few weeks), real users mentioned in their SCF pitch, or evidence of transactions on their site or Discord.


Step 2 — Claim your 5 products BEFORE starting (anti-collision)

To prevent two contributors from researching the same products:

2a. Check the comments on this issue and any open PRs with the research label to see which products are already taken or in progress.

2b. Leave a comment on this issue listing your 5 chosen products, for example:

"Claiming this issue. I'll be researching: Product A, Product B, Product C, Product D, Product E"

2c. Within 24 hours of that comment, open a draft PR with 5 placeholder files (using research/template.md with just the header filled in and status 🔄 In progress). This formally reserves those products.

If more than 24 hours pass since the comment with no draft PR, the claim is released and another contributor can take those products.


Step 3 — How to reduce contact friction

The goal is to get a response. Every detail matters:

Speak their language. If the project has a founder with a Latin American name or a pitch in Spanish, write in Spanish. If it's an African or Asian project, write in English. If their profile is in Portuguese, write in Portuguese. Check their socials or SCF pitch before writing.

Use the channel where they're already active. If they're active on Discord, use Discord. If their founder responds on X, reach out there. Don't force them to switch channels. Check which one has the most recent activity.

Reference something specific about their product. Don't send a generic message. Show you did your homework: "I noticed that in [product] users do X, and I wondered how you handle cases where Y...". That's what separates your message from spam.

Keep the first message short. The hook needs to fit in 3-4 lines. Send the questions only once they confirm. Don't dump everything at once.

Offer something in return. Close the first message by leaving a door open: "if you're interested, I can share more about what we're building in the ecosystem." Reciprocity increases response rates.

Opening message template (adapt based on channel and language):

"Hey [name], I'm collaborating with Slice, a protocol in the Stellar ecosystem. I'm not here to sell anything — I'm researching how projects in the ecosystem handle conflicts between users, and [project name] seemed like a really interesting case. Would you be up for answering a few questions over text? It won't take more than 10 minutes, and if you're interested, I can share more about what we're building."

If they don't respond within 5 days, one follow-up is fine. If they still don't respond, document it and move on to the next product.


Step 4 — The questions

Send the questions one at a time or all together depending on how the conversation flows. The order matters: the first ones are the least invasive, the last ones are the most revealing.


Question 1 — Problem existence

"Do you have (or anticipate having) conflicts between two users of [project name]? For example: someone saying they didn't receive what they paid for, a deliverable that didn't meet what was agreed, or funds that got stuck because both parties couldn't reach an agreement."

(Confirm the problem exists before going deeper. If they say they don't have any and don't anticipate any, this product isn't the right candidate.)


Question 2 — How they handle it TODAY (the most important one)

"How did you handle the last time something like that happened? Walk us through it step by step: what did the team do, how long did it take, who made the final call?"

(Always ask in the past tense. "The last time" forces them to describe what they actually did, not what they'd theoretically do. This is where you discover the real workaround.)


Question 3 — The real cost of the workaround

"Is there anyone on the team — an employee, moderator, community manager — who handles these kinds of situations, even if only part of the time? How much does it cost you, roughly, in weekly hours or in money?"

(This question detects whether they're already paying to solve the problem. If they have someone for this, the pain is concrete and quantifiable — that's the strongest signal of real demand.)


Question 4 — The human and reputational cost

"What's the most frustrating part of how you're handling it today? Was there ever a case that resulted in losing a user, damaging the project's reputation, or where the process felt unfair to one of the parties?"

(Three layers of pain in one question: functional — what breaks in the process; emotional — what generates frustration; social — what affects reputation or third-party trust.)


Question 5 — Ideal solution (without mentioning Slice yet)

"If you could design the perfect solution for this, what would it look like? Would you prefer to handle it internally with your own process, or delegate it to a completely neutral third party with no ties to the project?"

(Let them describe what they want before you tell them what you have. That way the answer isn't biased by your solution.)


Question 6 — Willingness to pay (only if the conversation is going well and there's a clear signal)

"If there were an external service that handled those conflicts automatically — without the team having to step in — how much do you think that would be worth to the project? Would you pay per resolved dispute, monthly, or as a percentage of the disputed amount?"

(Only ask this if there's already a clear signal of real pain. If the conversation feels lukewarm, save it for a second exchange.)


Step 5 — Document in research/

Fill out the placeholder file you created in Step 2c with all the responses, using the template from research/template.md.

The "Follow-up info" field is mandatory: leave your Telegram handle and the contact info of the person you spoke with. This allows private follow-up with you or direct contact with the product person if something relevant comes up.

If any question didn't get a response (they didn't reply, or the topic doesn't apply), document it anyway — that's also useful information.


Acceptance criteria

  • Comment on the issue claiming the 5 products before starting
  • Draft PR opened with 5 placeholders within 24h of the comment
  • 5 products that match Slice (active, with real users)
  • Each one with a completed research/[product-name].md
  • "Follow-up info" field completed: your Telegram + product contact
  • At least 3 of the 5 responded to the questions
  • Final PR ready to merge

Resources

Metadata

Metadata

Assignees

Labels

Type

No type
No fields configured for issues without a type.

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions