Post Mortem: Reciprocity’s Ask/Offer Matching App
We started Reciprocity to unlock the full potential of human connection.
We made a Slack app sold to professional community managers that intelligently matched community members’ asks and offers for advice, introductions, and resources.
Communities would thus benefit from increased member engagement, productivity, and most of all, human connection.
However, after more than a year on the market, we were only able to secure a few customers and three digit recurring revenue. Admins consistently stuck with manual matching or a vanilla Slack channel instead of allocating budget to us.
The app worked, but the business case was not there. Where did we go wrong?
In short, through unhealthy product development practices, we built a feature we as community members wanted to exist, rather than a product that community admin customers were willing to pay for.
Read this post-mortem for our story, learnings, and mistakes.
We’ll trace the trajectory of the startup’s life, share the startup advice we support and disagree with, then list our biggest mistakes, successes, and who might claim this space.
Part 1: Our Story
The Vision — open source the old boys club
Founder Amit had been working in open source development communities for years, where members are eager to help others and share questions publicly. He wondered why a non-technical Stack Overflow didn’t exist yet.
Quora and Google could answer pure informational questions, but they lacked the relational component crucial to advice and recommendations.
At Stanford, he was further inspired by a reciprocity ring exercise, where members share what resources they need and have in a circle. It was astounding what opportunities for collaboration arise from the simple act of sharing one’s “asks” — what’s something you’re attempting to do that you could use help or advice on?
What if software surfaced needs as they arose, and matched them to offers of other community members?
At scale, such a world would be one where people are closer to one another, solving more problems, and the ‘old boys clubs’ of resources shared behind closed doors would become open.
Like an invisible continent outlined by the city lights at night, this network could illuminate the hidden similarities and resources accessible to all.
These two branding exercises were very helpful for us as we sketched out what kind of company we wanted to be.
The Stanford Pilot
Then, while Communications Chair of his Stanford MBA class, Amit faced many of the same challenges that professional community managers face, and asked ‘Why isn’t there an app for this?’
- Middle-manning introductions between members and mentors
- Losing institutional wisdom through poorly formatted archives
- Answering the same questions again and again
The initial version of Reciprocity was a 1-week project developed as a one-off web tool for the Stanford class. It was just a side-by-side list of Asks and Offers, on down the page. People loved it, and the MSx administration asked Amit to consider turning it into something they could use for future classes.
We had early support and validation at Stanford, where they included Reciprocity as part of workshops and classes as paid pilots. View the word map of their asks and offers above.
Nearly every attendee or student used us during the event/class and we received positive feedback, but there was little sustained use despite outreach efforts on the admin’s part. We had no way of knowing if people followed up on matches, and it was hard to gauge our value.
We did achieve the noteworthy distinction of having 30% more students say they got value from the reciprocity exercise with our app, over the spreadsheet they were using before.
Read more about that number and the pilot in our Case Study.
Pilot Learnings in Hindsight
In hindsight, it’s clear that our product at this stage still had issues.
- People were uncomfortable posting. They didn’t know what to post, they worried they’d be seen as dumb, and they didn’t know what type of ask or offer made sense for a particular group.
- People didn’t know what to offer. Some people would look at us wide-eyed, incredulous that they’d have something to offer the group.
Stanford wanted us to be something we thought was out of scope: a full alumni platform, with outreach, events, profiles, matches, polls, and so on. We chased the idea for a while on the web app, but still no sustained traction.
It’s only now we realize what the administrator was asking us: automate the shitty parts of our jobs! What if we had fully shifted our model to “build a marketing, student and alumni management platform for university admins”? The market was giving us a signal that we weren’t interested in building.
Another way people understood us was as a mentor/mentee platform, but we never specifically designed for that. Our greatest successes (~$10k in contracts) were as parts of cohorts and events, and we didn’t specifically design for or pursue those markets either.
We were building a product untethered to a specific use-case, and we didn’t see that at the time.
Bootstrapping and the lean year
Instead, flush off a paid pilot with promising metrics, we did what good startups do and started fundraising in late 2019. However, as we polished our slide deck (above) and spoke to investors, something about the entire process seemed off to us.
- Why sell off ownership of our own project if we could meet financing needs ourselves?
- Did we really need to hyper scale growth to meet the revenue needs of outside investors?
We were already weighing these questions when COVID-19 hit in early 2020, and the ensuing fundraising climate made the decision much simpler. We decided to bootstrap the company using our own funds.
Amit and Corey both got consulting jobs to pay the bills, and carved out time to spare time to supervise development.
Resources from Zebras Unite, Andrew Murray Dunn, and others on alternative capital structures helped remind us that there was more than one way forward here.
The Slack App
We used this time to develop a Slack app. Our customer interviews to date indicated that community admins didn’t want to make their members download another app, as they were having enough trouble engaging them on the existing ones.
Slack seemed like the best community platform for us, as opposed to the Discord cheapskates or enterprisey Microsoft Teams. In retrospect, that’s an assumption we could have validated more — though it was clear the web app was not the way forward.
We spent 2021 building this app, and adapted the web app’s functionality to the Slack UI. You can see what the finished product looked like in this demo video (above).
However, after launching in early 2022, we spent a year on the market selling, and here we are writing a post mortem. :(
So! Where did we go wrong?
Part 2: The Learnings
Startup culture repeats many tips often enough to become gospel. Here we’ll share two pieces of them we should have paid more attention to, and two that we recommend ignoring.
Gospel — Validate, then Build
The mistake that sunk the company was not having a customer-centric product development cycle.
This is startup 101. Y Combinator’s slogan is ‘make something people want’. The Mom Test book says to ask customers what they are already doing, not what they say want (since your mom will lie to you as she cares about your feelings). Agile software development puts validation before any step of any feature.
Somehow we strayed away from that.
We had a product that Stanford paid for (a web app that helped admins track what students needed and prompted engagement) so we took that and ported it to Slack without fully validating our featureset as something that non-institutional community managers in education wanted.
Once the Slack app was ready, we sold to dozens of community managers across many industries. Their needs and wants were close enough to what we already had that we kept building.
But wanting something and paying for it are different things. People would take our calls. They’d answer our cold emails. And then they would ghost us, lose interest, or push us back endless fiscal quarters.
We made a vitamin, not a painkiller, and as such they couldn’t get budget authority to pay, much less community buy-in to try it.
To avoid our mistake, ask yourself:
- Do people need your product? If so, when? Where? Understand all the particulars of the need to appropriately assess the market. “Occasional” products need either high payoff or large scale, and will need to emphasize customer awareness strategy.
- Know all your customers on the way to “everyone”. It’s very hard to sell to someone you don’t understand.
- Quantify customer feedback and learnings from the very beginning, and adhere to the practice. Sales efforts deserve as much reporting and automation attention as the product. Build Slack reporting of KPI’s early on.
- Hear people when they’re telling you what their needs are. You may need to look behind the words. But you must always be validating that:
What you thought was a need is a need.
Your product solves their need.
The need is bad enough for them to pay money around it.
Gospel: Not just MVP, but MSP
We also built too much of a product. A product that could have been credibly called Viable, but it empirically wasn’t very Sellable.
We now know that confirming a product is sellable is more important than confirming it works. We may be redefining acronyms here, but a MVP product won’t necessarily sell. An MSP could be even less functional than an MVP, but if someone pays for it, then you’re off and running.
To do this:
Start with customers with short sales cycles — people who can pay you today.
Choose one customer who will pay, and build what they need.
Use service engagements to build resalable product.
Measure value of service engagements in terms of how much runway they buy you, or how they’ll help you evaluate PMF.
We ended up building a product that was far more than MVP for the Slack app. We could have built something smoother, lighter, and gotten that in front of admins faster. And that may have caused the product to pivot farther away from the asks/offers matching we had envisioned.
But it’s worth it to be ruthless with your product. Nothing is sacred. If you have to Hail Mary, you may as well do it as soon as possible.
In the end, the market wanted one thing, while we extrapolated what we already had into what we wanted to exist.
Blasphemy — Don’t Burn the Boats
One piece of gospel we’d advise against is burning the boats. This is classic startup advice for founders, to quit your day job and go all in on an idea, without any distractions or escape paths.
Amit did this from 2018 to 2019 on the advice of Stanford peers, and he regrets it.
The advice to go “all in” can only come from privilege. From a place where financial devastation is unimaginable. From a place where failure isn’t devastating to one’s self and family.
Amit’s travails, with no safety net for unexpected disasters, dragged his family into financial support. Don’t put your life and family at risk for a bet.
Blasphemy — Go Indie
The other piece of startup gospel we’d recommend against is raising venture capital funding right off the bat.
There are plenty of think pieces out there about when to do this or not. When you’re in a land grab against well funded competitors, of course you have little recourse but to fundraise. One of the Uber founders even infamously once said:
“Excessive fundraising is not my preference, but it is required when the money is available.”
But if you were like us, sketching out a fresh niche of a new community vertical, it truly wasn’t necessary. We could afford to fund it ourselves with a small team, and we maintained far more flexibility as a result. Even now, we don’t think this decision affected the viability of the company.
There is a whole world of independent startups out there, with success stories to boot. TinySeed, Microconf, Indie Worldwide, Slow Capital — the list goes on.
Ask yourself — do you really need to raise outside funding, much less institutional capital? Or can you prove demand and concept first on your own?
Part 3: The Mistakes
Here we’ll share several more mistakes that hurt us, taken straight from our internal team post-mortem.
Flawed user testing
The results we received from user-testing didn’t reflect the reality of actual user actions which led to big time and money losses.
Development was going ahead of what stage the product actually was. Our minimum viable product was very well made, feature-rich and with long-term-oriented features. The web app analytics, super admin dashboard, and slack analytic features were all developed but not used.
Learnings:
Follow The Mom Test book to the letter in user interviews.
Record all user interviews. Have them think out loud.
Don’t use your friends — use target audiences in a realistic environment.
Have standardized goals and questions.
Lack of data-driven decision making
If we had a clear strategic plan with conditionals, we’d be forced to define success/failure conditions and spot red flags earlier, which lets us change the direction of the company if needed.
Instead, we had a deceptive goal — port the web app to Slack, then launch.
Making decisions is what determines success of a startup. Not putting enough time, effort and consideration into the decision making process is expensive on many levels:
Values of developed features are low, or not extracted later with a follow-up.
Accepted solution isn’t the best solution.
Missing the big picture, overlooking the underlying problems and red flags.
We should have made sure we verified our proposed solutions instead of immediately passing them for implementation. Over time, this led the company farther away from the customer.
If it’s addressing a problem or user feedback, we should make sure to dig into underlying problems, verify that it’s addressing the correct problem, brainstorm solutions, pick the best solution, write a task for it, then review the made things and verify it’s the best solution. Only then should it pass on to implementation.
Learnings: when about to make a specific product task, ask:
What is the problem that we are addressing? Is there an underlying problem below it? Are we addressing the right problem?
Is this the best solution? Can there be better solutions?
After deciding on a solution, make a task with all details about it. Then verify the solution with the team.
How are we going to measure or verify the success of the solution? How do we know it actually solved the problem?
Implement the solution, then execute verification/measuring of success of the solution.
Assorted other Mistakes
- We hired a pricey contractor without work limits who then worked 5x more than we wanted, with the astronomical price tag to boot. Learning: Constrain billing and scope on all contractors. Require timely communication and time reporting. Require work to be tracked and updated regularly in project management system.
- We hired a copywriter for all our bot’s messages that ended up confusing users with marketing speak rather than clarifying what the next possible steps were.
- We spent a month or two in review limbo after submitting the app to Slack, which we could have planned our sales efforts better around.
- We spent a month or two of time and money creating a startup explainer video with many revisions, that we decided to scrap in the end. Chances are you can find an easier way to explain your startup than a video.
- We never truly solved the Offers side of things. People struggled to shrink their entire lives into distinct Offers, and Asks have nothing to match to without those.
- We labored over a thoughtful Ask wizard that people didn’t use, preferring their existing behavior of posting normal Slack posts in an asks channel. Learning: User friction must justify itself.
- We thought having the admin introduce the app once was enough for members to use it. Of course not! Savvy admins would bulk add members to the channel with a third party tool to solve — a behavior which we could have eased.
- We focused on selling to the enterprise customer, but we didn’t give them tools to see ROI. Dollars make dollars.
- Our MVP was low usability and high friction in both product and copy. Product design wasn’t paying enough attention to user stories and user behavior.
Conclusion
The Successes
- Bootstrapped a community-first product to market.
- Strong bonds between team members allowed the team to persevere through both a surprise war and a surprise child.
- Contacted dozens of thousands of people in the target audience via cold emails and Linkedin outreach.
- High quality distributable code stack across MongoDB, GCP, node, and Heroku. Elite-level Typescript and React code.
- Developers learned a wide variety of platforms and library expertise. Slack, Sendgrid, intercom, auth, mongo, unit testing, load testing, webflow, notion, jira, miro, react libraries (MUI, theming, infinite scroll, routing), node libraries (express, orm, api’s and middleware), database concepts (sharding, triggers, cloud hosting).
Will someone else claim this space?
Now that Reciprocity is gone, will another contender claim the Ask/Offer matching space?
Someone may claim the adjacent spaces: that of community engagement, mentorship cohorts, or HR team-building. Ask and offer matching may be used as a feature within those products, but after Reciprocity, we think it will not be a standalone product itself.
We made a huge spreadsheet of players in the community engagement space, but most of them have folded or stagnated since then. In a move reflecting aspects of our own journey, the founder of the ask/offer matching for nonprofits startup Switchboard even left it to found Zebras Unite, the community for indie entrepreneurs mention above.
Intros.ai and Donut are the closest operating companies to Reciprocity by matching team members 1:1, albeit randomly instead of based on actionable ask/offer data. Both check the team-building checkbox.
The most funded community startups are those that address the problems that customers will pay for.
Commsor and Common Room are nominally community apps, but in truth they are enterprise sales analytics products that tie community efforts to revenue. That’s where the money in the community space is. They’ve also done a great job of thought leadership and of mapping the space.
Perhaps there is an innovative and distinct pricing model out there that charges admins or members to match community needs. But after this startup, we don’t think that’s a viable value proposition, and that it will instead be a feature within a wider product.
Farewell
As our landing page proudly proclaimed: ‘To go fast, go alone. To go far, go together’.
We definitely went far together, even if we didn’t make it to our destination.
To all the Reciprocity team members, contractors, stakeholders, advisors, customers, testers, admins, and members: it was an honor to go far with you.
