The CrafterFaster Journey Begins

An "open-source post" on my career transition, as well as how I'll be approaching product-related user research, retention, acquisition, and monetization

I've always been enamored by people who create something from nothing. Drawn by makers who aim to make the world a better place by creating game-changing companies, and equally mesmerized by makers who elicit a smile on my face through their art, content, products, and expertise. There are now many people using their individuality in some way to make a living, independent of an employer, that include different verticals but are not limited to: dance instructors, winemakers/vineyards, video course creators, accountants, newsletter writers, voice actors, podcasters, indie programmers, community organizers, YouTubers, mangaka, and the many more classes of jobs that haven’t even been created yet, but will be enabled by the distribution mechanisms of the Internet. I refer to this entire class of people as creators, makers, and builders, despite all of the different influencer, content-creator, social media-related, and tech-related definitions that exist for the three terms.

Those following me on Twitter might know that I started a side-project LLC company in January 2020 called CrafterFaster. CrafterFaster is ultimately a love letter to this ever-growing population, as today's culture and technology is slowly enabling these builders to participate in the passion economy and make a living off of their individual skillsets and interests.

The CrafterFaster mission is to enable all makers to have control over their careers and the other important aspects of their lives. The 10-year vision of this is to enable anyone to become a skilled, fulfilled, and successful creator. Anyone who has a vague idea of a business they want to start around what they're most interested in can immediately get the ball rolling with CrafterFaster products and apps. They’ll be able to:

1) have the bandwidth to become even better at what they're already creating (i.e. skill),

2) become completely satisfied with the life both inside and outside of work that they are living (i.e. fulfillment), and

3) make a living off of their new business super quickly (i.e. success).

Transitioning from Holberton to CrafterFaster, a COVID-19 tale

Even though I've been doing a full-time job that I love, working as a software engineer at Holberton School, I knew that CrafterFaster was something that I had to work on. Since I had steep San Francisco apartment rent to pay, I decided to work on CrafterFaster part-time during nights and weekends when I didn't have my hands full with Holberton work. Unfortunately, the reality was that being one of a handful of software engineers at a very quickly-scaling, series B startup turned "nights and weekends" into an occasional "night here" and "weekend there."

Just a month after forming the LLC, early COVID-19 warnings and cases started to make their way into my February Twitter feed. The first San Francisco COVID-19 cases started to surface when March rolled around. Just a few days after, Holberton issued a company-wide message stating that all employees will be working remotely from home and away from people until further notice.

Remote work was hard at first and took a month to really get used to. In a time of great uncertainty and chaos, I wasn't thinking too much about my new venture and put the vast majority of my effort into my steady full-time job. Despite this, I was able to get a little bit of feedback, from amazing people like my sister, Li Jin, Ryan Hoover, and many others, on initial sketches, docs, and prototypes that I created with the help of Tanthai Pongstien. As April arrived, the thought of whether or not I should renew my rent came to fruition. I talked it over with my family and we realistically knew that the pandemic was not going to go away anytime soon. "Do I want to stay in my apartment by myself for another year?" "Would I benefit from an in-person support system living with my family?" We all conferred on such questions and I decided that it was definitely best for me to move back home.

I broke the news to my direct manager Guillaume Salva in May. He was totally cool with me moving back, since I was working well remotely from SF and that a change in location wouldn't affect that. I flew home on May 30th with all of my stuff and socially distanced myself from my family for 2 weeks.

Similar to how I was able to regain my productive work rhythm, the problem of not being able to allocate enough time to CrafterFaster also persisted. Being at home gave me a solid emotional footing that I could anchor on. As a result of having that footing, feelings of regret that had been welling up for the past year had begun to surface in the form of really bad sleep. At first, I didn't understand why that was. However, I started to gradually piece together the correlation between my bad sleep and my lack of progress on CrafterFaster. When I finally understood that correlation, I knew that I had to make the full-time jump to CrafterFaster. My body instinctively knew what I needed to do and now my mind did too.

It took a few days to convince my family that this was the right move for me and starting a creator-focused company at this point in time isn't as risky as they thought it would be. The issue of rent wasn't a problem for me since I would be staying with my family until COVID-19 resolved. The issue of health insurance was brought up, so I cited a tweet from Erik Torenberg talking about how the On Deck program that I had recently applied for will be providing fellows with health insurance. The issue of COVID-19 being a damper on business was brought up, so I explained that, while some businesses like Airbnb are experiencing a COVID-19 headwind, COVID-19 is providing a tailwind to a lot of creator-focused businesses. Lastly, the issue of the viability and potential growth of the market was also brought up, but that was a non-issue as I cited several instances of solopreneurs and small groups of people from all of the different creator vertical types that I listed above making a decent income. We were all aligned in the fact that I would be moving forward with CrafterFaster full-time.

About a month after this decision was made, I broke the news to Guillaume during our one-on-one that we have every two weeks. He understood where I was coming from and acknowledged that it's never easy to break this kind of news. Guillaume has helped me grow so much as a software engineer and I'm super grateful to him. A couple of hours later, I got a call from Julien Barbier, the CEO and co-founder of Holberton. He was super excited and supportive of my move. We had an energetic 30-minute conversation, talking about: how he decided to make a similar jump when starting Holberton, transitioning from a "product-focused" to a "company-focused" CEO, fundraising, equity, governance, and a lot more.

As my last day of September 1st quickly approaches, I'm reflecting more and more on how thankful I am for my 2.5 years at Holberton. I've grown so much as a person because of my experience with the Holberton team. Now the CrafterFaster journey begins.

Evaluating my Current Situation

When considering the concept of Total Addressable Market (TAM) and its potential growth, which is more important to me, I think about it in two ways. The first way is by looking at a discrete persona that is bound together by a Common Abstract Behavior, or CAB for short. In this case, winemakers, newsletter writers, fitness instructors, podcasters, and others are bound by a CAB — creating. Do I believe that this group of employer-independent people bound by this CAB is going to grow? Yes, I wholeheartedly do. One question comes to mind — is this behavior sustainable? As I stated in my definition of what encompasses a creator, they need to be able to keep on creating with minimal friction. When thinking about minimal friction in a real-life context, it all comes down to making a sustainable income. Do I believe that the world can get to a point where a majority of this creator population can make a living with their individual interests and skillsets? Again, yes. There are companies like Patreon whose entire value proposition is predicated on this promise. With that said, the fact that creators can constantly create with a steady income automatically unlocks use cases that startups can solve for. Some of these use cases might be tried and true, but are currently being solved in super hard to understand/execute, slow, expensive, or inaccessible ways. Some of these use cases might be new and novel, untouched in a pristine state for reasons unknown. Some of these use cases might not even exist yet. I believe that the value of these particular non-existent use cases will likely be generated and captured by the biggest creator-focused companies of the future.

The second way I think about TAM is by looking at it through the lens of a particular use case. While a persona is a highly-generalized characterization of some type of person or entity, a use case is a particular situation in which a product can be used. For example, when Uber started, they wanted to reduce the cost of direct transportation. When it comes to a particular situation, that's pretty broad. The target persona of direct transportation is pretty much the entire global population. Targeting the entire world from the start is an impossible task and a great way to lose focus when trying to actually create something valuable. This is why they first started by allowing users to hail a luxury car. This kind of use case is not for most people and is only limited to a few different type of personas. As a result, an example simplified TAM of the luxury car use case can be calculated by multiplying the average revenue of a single ride by the total number of rides that customers take in a luxury car. Taking the zeitgeist of that time into account, was this behavior of taking a luxury car going to become incredibly commonplace? Looks like the answer was no, as Uber added market cap in other ways by layering on use cases like: getting a reasonably-priced ride to and from the airport, getting a ride home with your friends after a crazy night out, using the product to commute to and from work, getting food delivered with Uber Eats, and more.

Taking all of this into account, I created CrafterFaster as a company building solely for the rapidly-growing general creator persona, with the intention of addressing all kinds of use cases as an eventual end result. As opposed to solving a general problem for everyone in the world like transportation in the Uber case, I want to build for the creators that I love and admire. As a lot of nascent makers have been lonely stuck in quarantine for months, I wanted to focus on my go-to-market strategy around that second pillar of fulfillment from the CrafterFaster 10-year vision. I called the first CrafterFaster product WarmPush, where the value proposition was to "deepen your personal and professional relationships by accomplishing your creative goals." The idea behind this was that most creators are adamant about achieving a strong sense of happiness, satisfaction, and productivity from their work. However, in our modern society, we’re all starting to realize as human beings that we also want that same sense of happiness, satisfaction, and productivity from all of the other important facets of our lives. The reception on prototypes that I was sending around was generally good. Then I started to realize I made a huge mistake I made when I got some very valid feedback from Reforge founder Brian Balfour. Here's a relevant excerpt of that feedback:

It feels like V1 could still use some narrowing down. The value props of feedback on the work as well as the "assistant" that helps you keep motivated and on task are different things. One has to be more important than another. Trying to accomplish both at once is going to muddy the initial feedback and direction you should take. I would focus on one use case as a hypothesis then iterate from there.

He was completely correct. I broke the cardinal rule of the need to focus on only one use case at first. A lot of entrepreneurs usually don't think about this rule when initializing the direction for their product and company in general. Countless entrepreneurs fall into the trap of being dead set on shipping a particular implementation of a product with all of the "bells and whistles" to customers. In the vast majority of these cases, most of these first iterations do not resonate. That rigidness in thinking leads entrepreneurs to think "oh, this next feature is really going to change everything." Except when it doesn't.

In my particular case, I was really attached to building under the CrafterFaster 10-year vision of enabling creators to become more "skilled, fulfilled, and successful," using quarantine to focus on that second fulfillment aspect when it comes to GTM. I guess I should feel lucky that I was alerted of my mistake super early on before any meaningful work got done.

To all potential founders out there, please focus on building for one specific use case at first, regardless if the vision for your company is big or small! So where does CrafterFaster go from here?

Validating a Problem and Picking an Extremely Promising Use Case

First, there are some definitions that need to be clarified. As previously stated, a use case is a particular situation in which a product can be used. On the other hand, the definition of a problem to solve is more variable. The problem might be super specific, and, in such a situation, might perfectly align with the use case. In the case of Zoom, the use case and problem are the same where the user is looking for a way to host a meeting where participants are remote. However, a problem also might be super broad, where the use case is just one specific way to address that problem. In the case of Airbnb, people might be looking to make extra income, which is the core problem faced on the supply side of the marketplace. The use case is a specific solution to that problem, where the user can host their home on the platform to make that extra income.

I know I want to keep the name WarmPush for now because it's easy to pronounce and spell. I also have the .com TLD, so that doesn't hurt when it comes to familiarity and SEO. However, it's crystal clear now that I need to settle on a particular problem and use case for the product. Should I focus on the collaborative use case of getting feedback on work? Should I go all in on the relationship use case with COVID-19 and quarantine as an entry point? Should I focus on another use case entirely? Should the use case converge with or diverge from the problem? I've decided to explore all of these avenues, so that I don't get stuck at a local maximum. When it comes to implementing this, I'll be conducting a lot of user interviews, focusing solely on people who identify with different creator types.

If you're currently reading this, consider yourself a creator/maker/builder, and wish there were something that existed in the world right now to solve a particular problem you're facing, I'd love to hear from you! Feel free to DM me on Twitter or email me if this is the case. Even if you're a potential creator who is just exploring and curious, I'd love to hear and learn from you.

When it comes to evaluating problems and use cases, I'll be looking for certain attributes:

Level of Intent

Is there a medium to high intent, where the potential user cares about solving a particular problem right now? However, that's assuming that they have a known problem they want to solve. If they didn't realize they had this problem before and were just introduced to its existence, would something click in their head telling them that they need to solve this? Is this problem a pervasive one that has largely gone unnoticed?

Adoption Potential

Is this a problem or struggle that is suffered by people of many different creator types? Can a use case be developed for this problem that fits the current zeitgeist and has mainstream adoption potential, unlike the Uber luxury car use case? If the use case has a maximum adoption scope, can another use case be seamlessly layered on to not ruin the existing product experience? If another CrafterFaster product is created to address a separate use case, can the potential value generated by this current use case be used to make that new product even better?

Natural Frequency

Are there any alternatives, products, and use cases that creators are currently using to solve this problem? What is the natural usage frequency of these alternatives? Daily? Weekly? Monthly? It might not be worth pursuing non-recurring problems or use cases that don't happen too frequently.

Mission/Vision Alignment

In my transition period, I was too attached to the CrafterFaster vision that I ended up trying to build for more than one use case within one product from the onset. However, I do think that it's important for the use case to align with the mission and vision of the company. I set out to help creators of all types to have control over the aspects of their lives, allowing them to become skilled, fulfilled, and successful. If the use case being evaluated does not fit this criteria, I will not go forward with it.

Trust and Safety

Does the problem and/or use case have trust and safety associated issues that need to be solved concurrently? Can trust and safety be natively built within the product experience? Trust and safety need to be thought about from the start. It's super important that anyone who interacts with the product feels safe.

I'm likely forgetting some important attributes, but I'll be evaluating potential problems and use cases with at least the above criteria. If, for some reason, the name WarmPush doesn't quite fit the resulting use case, I'll rename it to something more suitable that is still easy to pronounce and spell. Who knows, I might even call the product itself CrafterFaster if I think that the use case associated with it might completely dictate the future of the company.

Approaching Retention with the Resulting Use Case

Retention might be the most important aspect of a use case to focus on — there is no point in building something that someone will not repeatedly come back to and use. I obsessed over retention when it came to developing the early WarmPush prototype. I don't know the resulting use case that I will eventually land on, so I will go through the process of how I approached retention with the previous WarmPush prototype. However, my initial strategy was predicated on the notion of solving for two use cases at once and implemented with an unvalidated product/feature set, so proceed with caution.

Initially, I thought about all of the different actions that one was able to take in the WarmPush app prototype. As a result, I happened upon the action of "sending a message" being the one that would likely best correlate with an engaged user of the product. I made that decision for two reasons. The main reason was that the product was heavily focused around chat and the action of sending a message aligned well with the value being received in the "involving others in the creative process" and "deepening personal and professional relationships" use cases. The value that would be received in both of these use cases within the product is through the receiving of messages. If the user of the app wasn't periodically receiving messages on a basis matching the natural frequency of each of the use cases, chances are that the user wouldn't be periodically sending messages according to those natural frequencies as well. The sending of messages would be a good metric to see if the app was actually valuable and solving the problems that the user came to the product for. The second reason was that it was the action that had the highest amount of friction associated with it. If the user of the app was able to periodically perform an action with a high level of friction associated with it, chances are that they would retain.

With messaging being the action I focused on, I tried to work my way backwards in thinking about non-invasive, non-spammy, messaging-related habits that I wanted users to build within the app. To do that, I thought about the ideal habit experience that I wanted to occur and overlaid a tactical strategy on how to get there. Below was the habit experience I had in mind for the "involve others in the creative process" use case, followed by the tactical method on how I would go about forming that natural habit:

However, if users are not able to send their first message to someone and then get that initial piece of feedback or question answered, WarmPush can forget about creating a sustainable habit around the messaging action. For the sake of building this habit, I decided to slim down WarmPush completely to get the user to send that first message and receive that first piece of feedback. After the value prop of getting that feedback was realized would I then open up the full product experience. In my mind, there were two big necessary prerequisites in order to make this happen.

The early WarmPush app prototype was designed like Asana, but specifically for creators and with messaging built into tasks. Since tasks would play a pivotal role in order for the user to send messages and get feedback related to the respective task, the first big prerequisite for experiencing the value prop was to make it super simple to recommend what tasks users should work on right now.

Within all of the setup, I would ask for the type of creator that person is, as well as what their current mindset is. The three mindsets I included were pretty broad: "learning," "doing," and "promoting." Based on their creator type and mindset, they would be recommended with a list of templated, preset tasks to work and get feedback on.

The second big prerequisite to experience the value prop for the first time was to give the user a list of relevant people to get feedback from. The most feasible way I thought of doing so at the time was to have the user import their contacts through the iOS SDK during setup. After doing so, they would be prompted to pick at least three people who they think would give good feedback on their work.

Those two prerequisite steps were basically what I needed in order to get the user to send that first message and receive that first piece of feedback. After making that determination, I kept on going in reverse throughout the flow, thinking about all of the must-haves that I needed on the landing page and the rest of the setup in order to get to those prerequisite steps in the first place.

Initially going in reverse is great when you have an end goal that you want to reach in mind, but we as users don't experience products in reverse. As a result, I played out the entire experience forwards to see if it made sense. The entire activation experience did make sense and the UX was super fluid, at least for a product with an unvalidated feature set and muddled use cases.

All of my retention-related thoughts that went into the early WarmPush prototype were centered around activation. I did not think about engagement and resurrection at the time because I knew that even though the activation experience made sense to me, I had to test it with actual product usage. Planning out engagement and resurrection strategies at that point wouldn't mean much if the activation experiences were off the mark.

This was the process of how I approached retention with the previous WarmPush prototype. However, I now think that there is some value in putting thought into engagement and resurrection. These concepts don't live in a void and are not something that can be successfully tacked on without forethought. I'll likely repeat the same process after I've discovered the resulting use case to work on, while simultaneously thinking about engagement and resurrection as well.

Approaching Acquisition with the Resulting Use Case

I was mostly thinking about retention, particularly the activation experience, when I developed the first WarmPush prototype. Similar to my thought of incorporating engagement and resurrection strategies early on, I believe that acquisition should be included as well. Great products are built in a way that naturally attract more users. I don't know the resulting use case that I will eventually land on, so I will go through a small part of the process of how I would approach acquisition with the previous WarmPush prototype as a base. As I previously mentioned, my initial strategy was predicated on the notion of solving for two use cases at once and implemented with an unvalidated product/feature set, so proceed with caution.

Above is an image that breaks down the two use cases that currently reside within the WarmPush prototype. When it comes to planning out the acquisition strategy, I will have the use case and the respective natural frequency of the core action in mind. There would be no point to acquire customers only to have them churn because they weren't able to properly build a habit. As stated in the picture above, the target persona that I'll be trying to acquire in this exercise will be creators who are super early in their journey.

In order to decide the best way to acquire customers, I need to ask some questions. Is the product single or multi-player? It's very much a single-player tool, as I was inspired by Chris Dixon's "come for the tool, stay for the network" thesis. Does the value one receives from the product get better as they invite their creator friends? No, it currently does not. Can a current user be incentivized to invite their creator friends, and can the invited creator be incentivized to join? Yes to both. Can content currently be generated by a user, a supplier, or WarmPush itself and then be distributed in order to acquire new creators? Not at the moment. Can word of mouth be generated in order to acquire new creators? Yes. I don't think there is a huge differential between the current experience and expectation of the product that will drive that "oh my god, this is amazing" word of mouth. However, it would be folly to underestimate the value of FOMO-driven word of mouth in today's "Testflight era."

This leaves us with two initial flywheel templates to work off of — a give/get template and a word of mouth template. Let's stick with an example give/get loop since we have greater control over that entire experience as a whole.

This flywheel starts with a new creator who is early in their journey signing up for WarmPush. Their attention is piqued by the minimal cognitive load involved, as early creators don’t have to do in-depth research when it comes to the tactical things they have to do. They can also easily get feedback without having to switch between different apps and channels. In this regard, this "combined" primary value proposition is extremely compelling for makers who are just starting. After starting to use the product, the creator: works on templated tasks recommended to them because of the type of creator they are, taps their network, and gets super relevant feedback. However, let’s assume that the free tier of the product limits the number of messages they can send. Since they’re currently on the free tier of the product, they're limited in the amount of feedback they are able to get at this point.

After doing some digging, the new user finds out that if they invite their friends to the product who are also early creators, not only can they get unlimited feedback for a month, but the creator friend that signs up and uses the product can as well. Referring back to the customer retention canvas image above and the entire discussion we had around retention, the incentives that WarmPush is providing to both parties align with our core action and the habit that we want to create. As a result, the new user invites their early creator friends and the entire flywheel spins again.

This is just one example of one kind of flywheel that I would use within the context of the previous WarmPush prototype. After discovering the resulting use case I want to pursue, I'll start to think about different acquisition strategies and how they can be built natively within the product, instead of being hastily tacked on.

Approaching Monetization with the Resulting Use Case

Retention was top of mind when I was thinking about the initial WarmPush prototype. However, I wanted to initially position the product as a paid product. Therefore, I did think a little bit about monetization at the onset. Just like engagement, resurrection, and acquisition, monetization does not exist in a void. All of these concepts are interrelated and should be thought of as individual components in a system that is the product. I don't know the resulting use case that I will eventually land on, so I will go through a small part of the process of how I approached monetization with the previous WarmPush prototype as a base. As I previously mentioned, my initial strategy was predicated on the notion of solving for two use cases at once and implemented with an unvalidated product/feature set, so proceed with caution.

Even though I wanted to market the idea that WarmPush is a product that would be paid for, I was having trouble reconciling that with the fact that I also wanted it to be accessible for new creators. This led me to adopt a freemium monetization model for the prototype, where there would be no barriers from people initially using the product. The question at this point was how to scale pricing with the value being received by the creator using the product.

Ultimately, I decided to scale pricing on both a usage and a feature basis. As the core action of WarmPush is "sending a message," I did not want to limit the number of messages that creators, who wanted to use the product for free, were able to send. However, I did want to start charging customers on additional functionality only if they activated and developed the previously-mentioned messaging-related habit around the product. The usage-related value metrics that I used to scale pricing were:

1) the number of "helpful people" that could be added to each task,

2) accessing a certain amount of your most recent messages, and

3) the number of people you were able to add recurring reminders for.

The feature-related value metrics that I used to scale pricing were:

1) access to a list of all of the helpful resources recommended by experienced practitioners on each preset task, as well as

2) access to any and all experimental features within the app.

There is so much to think about when it comes to formulating a monetization model and aligning that model with the nuanced aspects of a particular use case. When I land on a resulting use case, monetization will definitely be top of mind this time around.

Non product-related work to be done

After finding the resulting use case to work on, my main focus will be on ideating, designing, and coding product, with a particular focus on retention, acquisition, and monetization. I've applied to On Deck in order to find that use case, and possibly also an empathetic co-founder who excels at design, finance, and/or engineering, but is a generalist at their core. CrafterFaster will also be raising a seed round in 2021 to build out a founding team. If any pre-seed and seed investors are interested in chatting, feel free to DM me on Twitter or email me.

This entire "open-source post" was inspired by the conversation that Li and Nathan Baschez had with Nathan Barry on their weekly Zoom show "Means of Creation." Nathan Barry was a big proponent of doing work in public, despite the fact that he was giving away part of his playbook. I'm really glad that I wrote down everything that I was thinking about, and I hope that everyone reading this post got something out of it! I’m planning to write more periodically in the future to not only to help out all of the potential entrepreneurs out there, but to also clarify whatever I’m thinking about related to the passion and creator economies.