Milestone: Demonstrate product market-fit
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)
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
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. 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
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
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
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
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
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.