The prototype remains yet to test our actual value proposition.
Testing the invite method.
Testing user sign-up flow.
Testing mobile chat as a concept (rather than facebook/reddit-like web chat).
Testing mobile notifications → user room engagement.
Testing “Discord” as the specific mobile chat app as opposed to Telegram.
Testing Discord Bots.
How to build them. What inherent limitations we have.
How to host them. We recently learned that the Resourceful application can have a bot living inside of it, rather than existing as a separate entity on a separate ‘bot’ server.
How to integrate them into a Discord Server.
How to pass forward and back data from Discord to Resourceful.
We started out with a concept for “Problem Rooms”.
We are now doing that same concept within a different container called “Rooms” or “Resourceful Rooms”. The reason behind this is because not all rooms need necessarily be problem based. Also the word “problem” is not a good word to have pasted everywhere.
We are working towards an MVP
The MVP delivers real value and confirms the product concept. In other words, it is “viable”.
The MVP doesn’t necessarily look like the prototype.
Further prototype re-builds could indeed be required before achieving an MVP.
The MVP automates a number of critical aspects of delivering the intended value behind the product concept.
The MVP is scalable.
The MVP will likely not change drastically, but will be continuously improved through iterations into a full-fledged product.
Problem Rooms
The concept behind “problem rooms” is arguably a good one. You bring in a single pain point, and the room builds an incentivised community around solving your problem. In a way, nothing exactly like this exists out there because there have historically been a number of challenges to implementing a product like this. Some of these challenges are very significant.
The Chicken/Egg problem of building a massive network to tap into. It’s difficult to provide something of value to attract a network, especially when you need the network in the first place to service that value.
Creating incentivisation structures to promote the exact kind of collaboration that will optimally reach a solution.
A one-to many payments marketplace. Few payment providers allow this. It’s difficult and expensive to develop (especially into an MVP). It can also be difficult to be approved by the payment platforms such as Stripe.
Platform algorithms that affect human behaviour can be complex and expensive to develop.
Problem solving itself has conceptual/framework differences depending on the type of problem.
A general purpose, catch all method or framework does not optimise itself for any type of problem.
Incentivised Connections
One of the very first meetings we had on the product/platform was about the incentivisation model around invitations. We concluded that there is currently no platform out there that really rewards people for sharing their valued and trusted connections. This fits our model because creating a connection from a room to another person is a critical part of the collaborative problem solving process. The challenges with building the incentivised connections are:
Visual feedback and trust in the platform. You want to be able to gauge what you are getting for sharing your value. This also goes the same for adding advice.
The ability to share without any barriers. Very simple sharing.
Resourceful Rooms
Moving to a more generic naming scheme opens up the possibility for the rooms on Resourceful to become a more mass-market model where rooms can become more than just for “problems”.
One of the important reasons to get this right early is because the naming scheme is implanted into the codebase, and becomes difficult to change later without running into errors, as the codebase is an interconnected web of semantic dependancies. A great example of this is actually Discord. They initially named their “Rooms” “Guilds”. They used guilds because they were targeting a niche segment in the market - gamers. Specifically the types of gamers that were into online MMO’s who would be in guilds hosted and managed by various different teamspeak applications. Now they have renamed the “Guilds” to Servers because it’s easier to understand what that is, and it is more mass-market friendly. This is however not yet reflected in their codebase. It is still called “Guilds” in the code.
Prototype
The prototype is not yet able to test the actual business concept as it requires a few basic features in order to begin testing the business concept. The MVP is the version of the product that actually tests the business value concept. In a way, the prototype is testing a few of the feature assumptions, how they work, and how to implement them.
In my opinion, we have made some mistakes with building a prototype.
Building with an unknown framework. It offers a learning curve to new developers, and takes away development hours from the lead developer to provide support to teach new developers how to code using the framework.
Going with graph data from step 1. Graph data is not a part of the core value proposition in the MVP business concept. Graph data is something that is part of a more long-term business value proposition. You could argue that it is good to get domain knowledge and experience working with graph data from an early stage, however it is something that is slowing down this part of the journey, which arguably should go quickly. Rapid iteration is the key right now.
Subdivided feature testing. Concept testing could have been further subdivided and tested along the way to reduce the risk of having too many assumptions all at once. For example... we could have hacked our way around testing the Discord chat experience in the absence of “private rooms” aspect not working just yet. The private rooms concept is extremely important for scalability, however once knowing and understanding the “how” to implement that and knowing that it is possible, we could have continued testing on a separate server that only contained one channel.
MVP
The MVP is to test the actual business value concept. Up until now it has felt like the MVP was completely out of reach because it requires a monumental amount of design and development work, which is compounded by the challenges and bottlenecks of building with graph data from the beginning.
Assumptions
There are a number of business value concepts that are pure assumptions at this point. It’s important to frame these assumptions within the context that they live within, so that we can understand how important they really are to address.
Assumption: Trusted Connections.
In this instance the context is... does a client care more that each connection who entered the room was a trusted connection, than they care about reaching a solution... at all... quickly... cheaply... of quality. Where does trust fit in the importance hierarchy of speed, cost, quality. Do we need to build the trust features from the very beginning, or can they come later?
Assumption: Problem/Solution Meta Data Structures.
In this instance the context is... who will ultimately use and benefit from the meta data structures around a problem and solution, specifically regarding the WAY a solution was reached. Is this a viable feature to improve the value of the platform? Will people pay for this feature? How will this feature be promoted, highlighted, and delivered? How much will this feature cost to build? Do we know how to build it correctly with what we know right now?
Assumption: Collaboration is always better than competition in reaching a solution.
In this instance the context is... what types of problem benefit better from a collaborative approach in reaching the desired outcome? Are there types of problems that are solved better by a competitive approach? Does the value distribution model need to be built in a flexible manner to allow the customer to pick their ideal type of model? For example, for graphic design work there are a number of platforms that have confirmed that a competitive model works better for the client to reach a solution quickly.
It may be that collaboration is indeed better than competition in the context of building a community, and building helpful relationships between people. But in the context of pure productive output and problem solving, sometimes competition might be better.
Assumption: More room participants is better in reaching a good outcome faster.
In this instance the context is... Are some problems better solved with fewer people who are more engaged? And are some problems better solved by more people who are less engaged? In this instance, we are mapping out the conceptual frameworks for solving different types of problems, and finding the formula’s that work best for different types of problems.
The Way Forward
After sitting down with Jonas, it became clear that we need to progress to testing our actual business concept much faster. Rapid iteration and testing is crucial for us to understand better how to overcome the inherent limitations that sprout up along the way.
The method he recommended is that we do everything in reverse. We start with the MVP and not the prototype. How? We do everything manually. We start solving problems moving forward as closely as possible with our proposed method of problem solving, executed manually. The way to do this is using a Resourceful Service Agent, who’s job it is to test drive the platform and product manually. If personal tutorials are required to overcome hurdles and obstacles to get users into the system because of poor user experiences, the service agent will help those users manually. If an algorithm needs to be developed to divide and distribute value, then the Service Agent will hypothesise, theorise, and report back on what that algorithm should look like based on the context of the problem.
The How: Do. Everything. Manually. It takes a lot of time, but in that process you learn exactly what is important, and what is not important. You spend fewer developer hours building things that you don’t need, and you frustrate developers less by binning the work they spent hours and hours toiling over because it was not designed correctly or needed in the first place. It’s a direct data driven approach to designing, testing, and delivering real value from the beginning.
The Roadmap
The immediate product roadmap over the next moon cycle should be focused on manually progressing towards executing the intended business value proposition. Whatever that takes. The way I see this happening is that once the next iterations of the prototype are finished being implemented, I will take on the role of the first Resourceful Service Agent to learn and understand what it takes to be a service agent.
In the first 2 weeks, I will focus on progressing towards one room/outcome while concurrently documenting how to be an exceptional service agent. In doing this, we have our MVP. Right now. By the end of the month, the goal is to have 2-3 service agents progressing 6-9 room/outcomes. Initially the focus is our internal room/outcomes. However I would also like to have at least 2-3 room/outcomes be from external stakeholders who are looking to achieve progress with their own needs. In doing this we will be forced to setup some rudimentary payment flows that can be executed manually.
Want to print your doc? This is not the way.
Try clicking the ⋯ next to your doc name or using a keyboard shortcut (
