Startup, Failure, Pivot
My personal founder notes on Picsplore Mark 1, a location based social network. I cover our first iteration from 2018 - 2021.
Picsplore Social
Picsplore was an idea Zachary, and I envisioned, developed, and eventually released. We envisioned a platform allowing users to see everything happening around them in real time. We would provide a constantly updating feed of locations such as Restaurants, Bars, Parks, and more, showing you the latest pictures posted by either friends or strangers. People would be able to see the current vibe of a location, which friends were there, and get an idea of what to expect, such as the crowd and if there was live music. The goal was to give a reason to get out and make memories, not an engine of endless scrolling.
The Problem
Most of the current social network solutions at the time were great at presenting what happened in the past tense, not what is happening right now.
When traveling to a new location, most people relied on a local or spent time researching interesting spots.
Unless you were in the loop, you did not quickly know where the excitement was.
Our Solution
Provide a real-time feed that shows users, based on their location, the most popular places at that given moment.
Give the users the tools to see which locations their active friends are currently at quickly.
Provide the ability to create posts with images tagged to a location. (We felt an image shares so much data in seconds.)
Development
To validate our idea, we asked users to look at our wireframes and ask what they thought. Usually, they would find the concept interesting and give us their ideas on what features are needed. (MAJOR MISTAKE)
Due to our idea relying on location and friends, we felt that the best form for our concept was an iOS Application. (This can be debated)
Neither Zachary nor I are graphic/UI designers, but we decided to design as we go, wasting time constantly resizing different assets and hunting down design perfection. (TIME-CONSUMING MISTAKE) This slowed our development time by months and was a complete waste of resources.
Regarding the Backend and Database, we prioritized the quickest to be built and were okay with locking ourselves in design-wise. This led us to Firebase, which is a NoSQL backend product, a product by Google (DEBATABLE). This allowed us to get core features of the database and backend built and working fast, but this slowed our development later on when attempting to implement features and queries that the platform was not designed to do right out of the box. This also slowed us down by weeks to a month.
In preparation for a public Beta, we populated the database with many locations, primarily around New York City. We also prepared for a massive launch day, with a Product Hunt Release and other platforms that show new software products. (ALL NEGATIVE INDICATORS)
Growth
The big day came, and we released our public Beta on the Apple App Store.
We initially reached out to friends and family, texting people directly, posting on social media, and even getting them to download in person.
When downloading in person, we would watch, not guide, the new user. Looking to see where and if they got stuck, how they would use it, and what we were offering to them. (This was good; this is where we learned the most)
We continued to roll out updates that we felt we needed. (MISTAKE)
LOL, we did paid marketing and stopped ourselves before going crazy, but still! (MISTAKE)
Failure
Failure hit us hard; it was self-evident, and looking back, we should have seen issues from the beginning. We hit just over 300 users, which we are proud of, but those users, after a week of playing around with our app, would never return. Retention is everything here, and this, for many reasons, is where we ultimately failed.
What was Learned
When we initially had the idea for Picsplore, instead of surveying people for their opinion on our wireframes and our envisioned solutions, we should have surveyed them about their process of interacting with their friends in person, how they decide on a place to go, what is a good night, what is a bad night, and more questions that are long-form and allow us to understand what people need and if there is a real problem.
We should have really debated further whether there are other potential solutions rather than building an iOS Application. Many times, it is easier, faster, and just as effective to release a website solution.
Before writing any code, we should have outlined the absolute minimum that needs to be built to create a product that can provide a solution and receive user feedback.
Once the feature outline is created, it’s time to design an MVP. Speed is important, so the designs should be easy to build and have no extra fluff. Once we have these designs and there are no changes from the survey or big goal shifts, we should stick with the design.
Make sure your backend and database can support the MVP. This is not the time to overbuild; think of a maximum of 100 users.
There will be no hard launch; think soft launch. You will not have millions or thousands of users on day one, week one, or month one. Build tools that create value for the user with few to no friends.
Once you have an MVP, don’t worry initially about growth rate; focus on retention. Your friends may be nice and use your product for two weeks, but if they are using it for four weeks or more, you may actually have something here. That should have been our initial goal.
Fix significant bugs, and don’t go crazy after the minor edge case bugs.
NO paid marketing. Think organic, think small.
Pivot
With every failure, many things are learned. We recently decided to pivot with Picsplore and started working on a new iteration, hopefully learning from our past mistakes and being ready to learn from our future mistakes.
We need a new name, so if you have any ideas, email me at thomasmjumper@gmail.com. Think friends and real-time hangouts.
"Near Me", a riff on searches like "(insert blank) near me"