top of page
  • Writer's pictureDarren Cody

Enter Scale-Up Mode - Case Study


Enjoy ScaleUp By Marketplace Studio


Marketplace Studio is enabling our clients to skip some hard lessons and proceed to see results through our ScaleUp program. We embed our core team into your marketplace but do not take direction blindly, instead evolving your concepts, testing, and validating by user testing.


We want to help. We want you to avoid the path of hard lessons. We want to share our experiences in an educational manner to let you and your team build something that will change an old social norm.


We will offer Design Thinking Sprints across multiple categories:

  • Pre-Development

  • Product Launch

  • Marketing & SEO

  • Strategy

  • Fundraising

  • Network Effects

  • Adoption & Growth


From a non-technical marketplace founder's perspective, there are several aspects of Marketplace Studio's offerings that could be appealing:


Marketplace Studio understands that post-launch, many marketplace founders require additional services to support their growth. By providing services that founders may not be able to handle themselves, Marketplace Studio aims to fill that gap and support its clients in achieving their goals.


The inclusion of Design Thinking Sprints with Product Managers and the UX Manager can be beneficial. These sprints can help founders refine their concepts, test ideas, and validate them through user testing. This approach ensures that marketplace concepts are thoroughly examined and refined before implementation.


Marketplace Studio's ScaleUp program aims to help clients skip some of the challenges and lessons typically encountered during marketplace growth. By embedding its core team into the client's marketplace, Marketplace Studio can actively contribute to evolving concepts, testing strategies, and validating ideas. This approach can provide founders with valuable guidance and support.


Marketplace Studio categorizes its services into different areas, such as strategy, fundraising, product improvements, adoption and growth, network effects, and marketing. This categorization allows founders to identify the specific areas in which they require assistance and choose services accordingly.


Overall, Marketplace Studio's focus on providing comprehensive support, customization, and expertise in various aspects of marketplace development can be beneficial for non-technical founders. By offering a range of services and incorporating design thinking principles, Marketplace Studio aims to help founders overcome challenges, refine their concepts, and achieve marketplace growth and success.



Why We Offering This


Marketplace Studio began as a specialty Product & Design service specializing in Marketplaces. Drawing from our real-world experience going from sketching napkin designs with 0 requirements and handing them to developers expecting them to read our minds and deliver the world to be left beyond disappointed. Growing to use Adobe XD to create what we called “Skeleton Frames”, (which we later learned are wireframes) and short descriptions, to morphing into 1-dimensional colorful designs and heavier requirements until we found out what User Stories are and how powerful they are in practice.


User Stories is at its core instructions for Developers on building the required Feature / Workflow / Design / etc. Combing these bulletproof recipes with fruitful designs, we were in a much better place development-wise. Our team’s output not only grew exponentially but also the quality of our product. A critical component of a User Story is the Acceptance Criteria, something the Developer can manually test themselves to ensure that a chunk of code is built to scope.


We finally launched our V1 (MVP) mobile app using a hybrid approach which meant a single code base instead of native apps that need one language per iOS & Android application. Now, it was time to sit back, relax, and wait for Users to come to us.


Let’s tackle these ‘problems’ in order when building a new marketplace:

  1. Napkin Designs

  2. Importance of Requirements

  3. Wireframes

  4. 1-Dimensional Mocks

  5. Low-Quality User Stories

  6. Robust “MVP”

  7. “If You Build It, They Will Come”


Napkin Designs

This might seem obvious but if you’ve done this, know that you certainly aren’t the only one! We speak to Founders all the time who’ve either done it when they started or are still doing it. Now, we’ve done it too so there is absolutely no shame, but in our experience, there is a better way. You can point holes in the napkin designs easily by looking back, but let’s focus on the expectations vs outcomes.


Expectations

We believed that a simple hand drawing would be enough for a Developer to understand how to build a 5-Step Signup Process. We thought they would infer what Primary / Secondary colors to use, a consistent uniform design, and the functionality combined with notifications & integrations. Basically, we expected a Michelin-star meal after ordering a double-double at McDonald’s.


Outcome

To say our expectations weren’t met would extraordinarily not even hint at what the Dev produced for us. (Again, absolutely no blame on our developer, he turned out to be a complete rock star later on!). Basically, it turned into a long single-page form to ask all the questions. This meant having to redesign it later on resulting in lost time & effort which is a low commodity in a fresh startup.


Importance of Requirements

We thought we were total experts at what we were building because it was going to be the world’s largest rent-anything marketplace! Out Founding Team had extensive experience in traditional rentals and even a few in tech startups. Our ego was just a little inflated because of this… Let’s just say that it is most likely that everyone on your team, especially the Development Team has the same life experiences that you do. In addition, it is impossible to read minds.


Expectations

We provided little documentation to our only Developer and thought (again) he could read our mind on the User Experience, Journey, Designs, and Data. Let’s see an example:


*Combined with a single skeleton frame*

I want a User to signup into the mobile app and go through the process of adding an item to the platform. We need; Title, Headline, Image, Price, and Location.


Outcome

Well, to our surprise, the result was something similar to our Signup Process earlier on in Development. Essentially, one long form asking the questions stated in the ‘Requirements’. Back to the drawing board for the Product Team - aka one person. This won’t do it.


Wireframes

When we started wireframing, it helped a tremendous amount! If you can picture a mobile app frame with a bunch of boxes and Xs which would represent input fields, buttons, and media; that is what a wireframe was for us. Super barebones and has nothing but black-and-white lines. We thought we solved the conundrum we were in!


Expectations

Now, at least we could show a User’s journey on a couple of different screens, what more could a Developer ask for? They should be able to build our Checkout process within a few days.


Outcome

The quick answer is no. No, that is not what happened. It was actually a TON of late nights or even all-nighters working with our Frontend & Backend Developers asking & answering a million and one questions.


“What happens when a User tries to pay for an item? How do we digest the money and pay it out later?”, “If there are 2 items, and only 1 is booked, how do we track the remaining item?”, “Does the Customer get an invoice or any type of email?”.


The funny and also amazing thing was that these questions weren’t coming from the Product Team, but from the two Developers. Needless to say, it took more than a few days to build.


1-Dimensional Mocks

Evolution is an amazing thing, especially in a Startup! We had graduated to stunning mocks of what’s to be built by our very own killer Developers! These were similar to our previous Wireframes but now in color!! Also, worth mentioning, we had updated the roundness of our buttons from squared off to a 30-degree corner radius resulting in a nice-looking interface for our Users but a backlog of effort for the Developers to change every button, one by one. Major learning, later on, the immediate importance of a Brand & Design System.


Expectations

“Okay, let’s unveil the curtain and see what magic you’ve done this time guys!” We know that the Review Process will be something that even {insert unicorn company} will eventually copy us for.


Outcome

Certainly getting a lot better, but still not perfect. We had the multiple screens show in a consistent manner, however, there are still parts missing. What did the button’s sequential popup or page look like? Where is the data we are collecting displayed later or is it even stored for internal reporting purposes? Again, the answer is either we didn’t think of it or not communicated.


Low-Quality User Stories

This was an empowering discovery, now we were able to think thoroughly about what we were building paired with our colorful mocks. This was great at the time and was how we did things for a long time. We had evolved from loose Requirements to effective explanations of the mocks we had.


Expectations

This time around, we actually had a handle on things. Now, this may seem like a long timeline, but this was probably in our 4th or 5th month of Development. We were finally able to communicate in a decently sized description to the Devs what we needed to build with the assistance of the mocks.


Outcomes

This had a tremendous impact on the output of the Developers and their effort. We were able to finally use Jira in the way it was meant to be leveraged by Product Teams. We could write Stories depicting the exact movements, outcomes, target users, time, and what to test against. Game changer.


Robust “MVP”

As some know, a Minimum Viable Product is basically the absolute least amount of “Features” (Marketplace Studio renamed these to Workflows) required for a User to complete an action that drives your North Star goal of the marketplace. North Star being Signups / Bookings / Postings / Referrals.


Expectations

We thought we completely limited the amount of effort required to build the mobile app but in truth, it was a mammoth of an MVP. Every time we ‘finished’ one feature, it turned into instant interaction based on our own thoughts. No testing, immediate implementation. We literally had Team meetings that included our Frontend Dev, we’d brainstorm and request him to make changes during the meeting.


Outcome

This did result in something incredible for the time (2017) but it was over-stuffed, without question. We lost a considerable amount of time & effort on Pre-Launch Development which meant less time in Production (real Users using the app) and giving us feedback on what needed to be changed or even added. Looking back, we could’ve released with half the features and completely avoided becoming a “Feature Factory” instead.


“You Build It, They Will Come.”

We thought we had released an absolute game-changer of a mobile app. Something that would shift consumer behavior and revolutionize the way people borrowed from their community. A few problems here, the first being changing consumer behavior is extraordinarily difficult when the social norm is to purchase an asset even when you need the item temporarily. Second, nobody really knew with the exception of our launch party that we were launching our rent-anything mobile app.


Expectations

When Netflix launched, they spent a ridiculous amount of time & effort getting their target Personas ready for launch day. Between Forums, Earned Media, or Word-of-Mouth, people knew it was coming. They hooked up a bell to their computer to ring every successful order. Apparently, the bell only stopped working when their servers crashed. We thought we’d have a similar problem.


Outcome

For our first booking, it was a short while after launch day. We had a partnership meeting with an Owner of a local gym, and we had to literally do it for the gentleman. We learned more from that moment that the duration of our Pre-Launch Development. The gym owner could not figure out how our instant booking checkout worked.


Failure Is When You Don’t Learn Anything

Throughout the 2 first years of this marketplace, we obviously learned a lot about how to do things and what not to do. One very important thing we learned that was invaluable later on once we were pushing hundreds of signups in a week, was “Do It Manually First, Automate Later”. This allowed us to; learn, and understand what problems occurred, implementation, requirements, and finally, how to leverage technology to save manual effort.


We had built something that blew our minds given our backgrounds and some of our inexperience. At this point, we had an innovative mobile app & a full-featured Website where Users could continue or complete any action on whichever device they wanted.


We learned what our Developers needed to build accurate features or dare we say read our minds because we had such an effective and descriptive form of communication. We knew what processes needed to be automated and more importantly, what the requirements were. We were miles ahead of our competitors and people liked the brand, and the company.


But there was still more to learn. If you aren’t learning, you’re regressing.



Adoption Analytics

When you launch a marketplace, it is notoriously difficult, no doubt. But we learned that just because we thought we created a gold mine, doesn’t mean people would come to mine it for us. We had intentionally embedded friction into some of our core features with the belief that so-called “Tire Kickers” would quickly abandon the marketplace and only high-quality Users would be on the platform.


This meant we knew we’d take a hit on conversions, but we didn’t know just how big and the impact that would have on the company and product. We partnered with Pendo, a Product Adoption Analytics tool to provide us with a behind-the-scenes look and what was really happening during our User’s journey in the marketplace.


The findings were surprising, however, not awful considering that it was an “MVP” and we hadn’t done any User Testing during our non-existent Pre-Development.


We thought our conversions on the important workflows would be high, something near industry standards. First, it was nearly impossible to find out what the industry standard was for a rent-anything marketplace because there weren’t many in 2018.


On average, people would convert around 30% to 40% on our Signup Process and something similar on our Posting Process. What is the point in blowing hundreds of thousands of dollars on marketing when only a third of Users complete the journey you want them to?


Marketing

This was the beginning of selling without talking via social media, but the more important lesson we came to understand was that none of our Users were intentionally going to an App Store and searching for either our company or a “Rent-Anything” marketplace. Our Web Platform was primarily our front entrance for organic or even paid Users. Search Engine Optimization (SEO) was to become our primary goal to decrease our CAC (Customer Acquisition Cost), Marketing Spend, and a couple of other budgets or costs. We needed to completely overhaul our Web Application as well as understand the techniques of the world of SEO and all of its incredible intricacies. It was time for Organic Discovery.


Operations

Circling back, one of the best lessons or decisions we made in the early days was doing it manually first to understand how to automate it later. Basically do what you can yourself until it's a problem and need technology to assist or take over later on.


We had an unimaginable Backend Admin portal to handle all of our custom-built features in our marketplace. Aside from the basic reporting or User management, what about our automated Positive & Negative Keyword tool which would automatically assign words to new postings that would rank them higher or lower based on the search term entered in our custom Elastic Search? Perhaps our Tax Regulation feature would manage tax codes based on specific geographies in Canada and USA when we reached a certain threshold of Users in that location.


What about our Custom Notification Manager, when a non-technical person could easily manage User Notifications? Edit, Add, Remove, or Replace SMS, Push, or Email Notifications based on an allotment of Triggers, Recipients, or Delivery Methods based on User Preferences.


We required any new items posted to be manually reviewed before they were approved or required adjustments based on our wonderful Curation Team. Instead of learning or reading the code in a database of raw javascript, we built a system that would replicate the Listing Page (we called this the Showcase) so that our Curation Team could see the listing as if they were a User ready to book. This exponentially increased the quality of listings on our platform. We could even change things ourselves if they were edits we thought would improve the experience for our Renters.


Design Thinking

A member of our Curation Team hosted a Lunch’N’Learn one Friday afternoon and introduced part of the company to her passion, Design Thinking, and how she previously used it to help build a product. It wasn’t long into her presentation that we knew we hit the jackpot of Product Development processes but it was also the evidence that she had real-world experience implementing Design Thinking into her previous company and the positive outcomes it had.


She was also a very talented designer and had quickly joined our Product Team of 3 to initially start facilitating our Design Thinking Sprints. We negotiated with our C-Team (Chief Executive Team) that we’d use Pendo to understand which feature was the worst offender in terms of conversions and spend a four-week Design Thinking session on a complete overhaul of the feature.


We followed the process rigorously for the month-long Design Sprint. For those reading who aren’t familiar with Design Sprints, here is a short summary of the process.


Step 1: Empathize - What’s the Problem? Who has the Problem?

Step 2: Define & Hypothesize - Why do they have the problem? What are potential solutions?

Step 3: Ideate - Brainstorm different creative solutions

Step 4: Prototype - Quickly mock low-fidelity prototypes and see what makes sense

Step 5: Validate - User Test, Make Updates, Test Again


Needless to say, for the final time, it was an incredible game changer in terms of success and conversion increase.


Our Listing Process for example had literally flipped. It went from an 8-Step Process down to a 5-Step Process, keeping in mind that the new process literally asked the User for the same information but in an entirely new way with better quality.


Think Marketplace Studio Can Help?

Let's chat and see what areas have the potential for us to collaborate on and embrace the Design Thinking methodology to enhance your Product Vision & Company's foundational culture - Being Curious.




Yorumlar


bottom of page