mirror of
https://github.com/logos-co/roadmap.git
synced 2025-02-03 03:43:47 +00:00
87 lines
4.6 KiB
Markdown
87 lines
4.6 KiB
Markdown
|
---
|
|||
|
title: Demonstrate product market-fit
|
|||
|
tags:
|
|||
|
- waku-milestone
|
|||
|
date: 2024-09-07
|
|||
|
---
|
|||
|
|
|||
|
## Milestone: [Demonstrate product market-fit](https://github.com/waku-org/pm/milestone/36)
|
|||
|
|
|||
|
To demonstrate the viability of Waku as a self-sustainable independent project, user traction and market fitness must be proven. Validation against the market of Waku’s technology and potential USP is needed.
|
|||
|
|
|||
|
Such validation can enable prioritisation of work and potentially dropping undesired features.
|
|||
|
|
|||
|
### Deliverable: [Define cost (self-host)](https://github.com/waku-org/pm/issues/247)
|
|||
|
|
|||
|
Cost of using Waku needs to be assessed to enable projects, including Status, to understand the potential ROI in using Waku.
|
|||
|
|
|||
|
The output of this deliverable should provide an estimate, in terms of infrastructure costs of using Waku for running:
|
|||
|
- Status 1:1 chats
|
|||
|
- Also cover RPC API prices
|
|||
|
- a community (whether done by Status or an external community owner)
|
|||
|
- Also cover RPC API prices
|
|||
|
- vanilla Waku, by using existing integration (e.g. railgun or the graph) as a reference.
|
|||
|
- all the above, adding RLN cost
|
|||
|
|
|||
|
Note: depends on PostgreSQL Optimisation - phase 2 deliverable for infrastructure costs.
|
|||
|
|
|||
|
### Deliverable: [The Waku Whitepaper](https://github.com/waku-org/pm/issues/248)
|
|||
|
|
|||
|
Write an academically rigorous whitepaper explaining the what, why and how of Waku protocols and ensure the coherence of the Waku technology.
|
|||
|
|
|||
|
As set out in [research#7](https://github.com/waku-org/research/issues/7). The document itself may source from one or more academic papers published and presented throughout the year. Total length should be around 15 pages.
|
|||
|
|
|||
|
### Deliverable: [Define potential USPs](https://github.com/waku-org/pm/issues/249)
|
|||
|
|
|||
|
Define Waku products and features, and potential problems they may solve. Some of it is already captured in the validation matrix.
|
|||
|
|
|||
|
This can be used as a basis when proceeding with market and product research.
|
|||
|
|
|||
|
Items can be validated, invalidated or new items can be recorded as part of research.
|
|||
|
|
|||
|
This deliverable includes an update of the waku.org website to ensure that the USPs are clear to potential customers.
|
|||
|
|
|||
|
### Deliverable: [Define target customers](https://github.com/waku-org/pm/issues/250)
|
|||
|
|
|||
|
Target customers and segments have been identified and presented in Athens all-hands.
|
|||
|
|
|||
|
A more formal capture should be done, with tracking in IFT CRM (using Segment attribute for example). IFT’s recommendation suggested a focus on the DeFi segment; experience has shown that intent and AI inference networks are promising.
|
|||
|
|
|||
|
A document should capture:
|
|||
|
- Customer segments
|
|||
|
- Market size of each segment
|
|||
|
- Potential problems and Waku USPs potentially relevant to segment
|
|||
|
- Competitors to Waku, other solutions in use
|
|||
|
- Learning so far, including interviews (next deliverable)
|
|||
|
- Rational in favour/against pursuing segment
|
|||
|
|
|||
|
This document + IFT CRM + Validation matrix are the core material for Waku GTM.
|
|||
|
~5 segments must be identified to proceed with customer interviews.
|
|||
|
|
|||
|
### Deliverable: [Customer Interviews](https://github.com/waku-org/pm/issues/251)
|
|||
|
|
|||
|
Proceed with ~10 interviews of current and interested customers, spread across the ~5 identified segments.
|
|||
|
|
|||
|
Understand their problems around peer-to-peer networking and capture in the validation matrix which of Waku’s offering may be of interest, or new problems related to peer-to-peer networking to be covered by Waku.
|
|||
|
|
|||
|
Interviews should have a dedicated ~5 questions to get answers:
|
|||
|
- Role of p2p network protocol
|
|||
|
- Current problems
|
|||
|
- etc.
|
|||
|
|
|||
|
To help establish the product-fit and identify potential blockers. This is should be detached from Waku, more about discussing p2p network and messaging role in the project’s protocol and their challenges.
|
|||
|
|
|||
|
When synthesising the interviews, a review of segments should be done to select and focus on segments with most potential.
|
|||
|
|
|||
|
### Deliverable: [Co-design sessions](https://github.com/waku-org/pm/issues/252)
|
|||
|
|
|||
|
At Devcon 2024, organise 3-4 co-design sessions to sit down to discuss potential Waku integration in more detail. Targeting customers in most promising segments deduced from customer interviews. This acts as a follow-up to the customer interviews deliverable and will require Waku engineers to attend.
|
|||
|
|
|||
|
### Deliverable: [Review Waku MVP](https://github.com/waku-org/pm/issues/253)
|
|||
|
|
|||
|
Based on customer interviews and co-design sessions, identify the Waku USPs with most potential and outline an MVP.
|
|||
|
|
|||
|
Based on Waku’s current state and roadmap, review if additional deliverables to fill technical gaps (if any) are needed, or what currently planned deliverables must be completed.
|
|||
|
|
|||
|
Communicate with targeted customers on MVP.
|