Welcome to the final installment of thoughtbot’s Womanish Incubator series! It’s been an enlightening ride filled with emotions such as, excitement, worry, and back to excitement again - all as we worked towards getting clear on the problem we’re solving and identifying our early adopters.
During the early stages of our collaboration with startup founders Dionna & Danyelle, we continuously worked on identifying and validating our assumptions through conducting interviews with our target personas and analyzing our market through competitor research.
After our initial user interviews and research, we took that knowledge to inform the second phase of the project. This knowledge helped drive our market segmentation pivot after invalidating our initial target persona, helped us improve how we facilitate our interviews to get the most out of each participant, and paved the way for our initial conversations with existing members of the Womanish community. In this second phase, the product validation phase, we all got to put our product hats on and engaged in a mini 3-day design sprint.
The goal of the design sprint was to identify and align as a team on our problem statement. Then, keeping this problem statement in mind, develop an initial prototype that we could put in the hands of potential early adopters to get feedback as quickly as possible. The process involved in creating this clickable prototype in Figma looked like this:
- Begin with a Speedy 8s exercise: This was a fun exercise that gave each team member 8 minutes to quickly brainstorm and sketch out 8 potential ideas that solve the problem statement we all agreed upon.
- Identifying the critical path: The speedy 8s exercise helped us pull out common themes around ideas every member had and use these common themes to identify essential features and functionalities to prioritize in our prototype.
- Storyboarding: Given our critical path defined, we then were equipped to sketch out storyboards that visually map out the user’s journey and interactions.
- Prototyping: Equipped with our shared problem statement, a clearly defined critical path, and a visual representation of the solution, we then created a prototype and a user interview script for that prototype to get it in the hands of the Womanish community.
In this post, we’ll take a look at what we accomplished during the last phase of the project, what we learned, and what insights I gained as a software developer that we can utilize when working with our clients to build software.
Womanish: A Quick Recap
Womanish is a social club and the creator of immersive experiences that connect and support millennial women. Founded in Chicago, the two founders started by creating in-person immersive exhibitions for and about women that garnished over 64,000 customers and generated $2.6MM in revenue. Continuously speaking with members of the community, the founders started noticing trends in the market and an unmet need that a lot of these members were expressing.
Womanish’s Opportunity Framework
In this most recent phase of the project, we’ve worked collaboratively as a team to develop and refine Womanish’s opportunity framework. This framework is based on the Lean Startup Canvas which is designed for startups and entrepreneurs who are in the early stages of developing their business ideas. It emphasizes rapid iteration, lean methodologies, and customer feedback to validate and pivot ideas before extensive resources are committed. The focus is on problem-solving, solution identification, customer segments, understanding customer needs, and developing a unique value proposition to address those needs.
Our version of the opportunity framework takes on more of the form of a pitch deck but in the form of a document (rather than powerpoint slides) and borrows heavily from the Lean Startup Canvas. The goal of building this document collaboratively as a team serves two purposes:
- To clearly define the problem, opportunity, solution, and strategy.
- To use this research to clearly communicate our pitch to potential investors so we can effectively argue our relevance and strategic positioning in the market.
- To not get lost in great branding to make sure that the business case was solid.
When creating our opportunity framework, we worked hard on answering the following questions:
- What is happening in the world that makes this effort necessary and timely?
- What is the problem? (and how do we know it’s a problem?)
- Why is the market ready this?
- What is our research-backed solution?
- How is our solution different from what’s out there right now?
- How do we know this specific solution shows promise - what research/experiments have we done?
- What is our go-to-market strategy?
The key takeaway from this exercise, for me, was that some of these questions were truly hard to answer at first - but this was good news! The questions we initially struggled to answer shined a light on research we still needed to do. For example, we all had a pretty good idea of what was happening in the world that makes this effort necessary and timely. The founders had a lot of empirical evidence but we still didn’t feel too confident about our claims and wanted more data to back this up. After conducting many more user interviews, however, a clear theme emerged that highlighted a lot of the answers to this question. Now, we not only had empirical evidence to back up our claims, we had real data!
Technical Analysis
Throughout most of the incubator project, I’ve had my product hat on. Focusing on identifying and validating assumptions, market segmentation exercises, user interviews, design sprints, and storyboarding, without utilizing much of my technical experience. Although I’m confident that my technical experience and knowledge influenced my perspective throughout these exercises, and therefore adding value, I was excited to use my experience directly to create a technical analysis of a Womanish MVP product.
This research resulted in a document that is intended to kick-start building the Womanish product. It can be used by a technology team to make a plan and cost/effort estimate for the build, as well as, to identify potential risks and areas to research more deeply.
This research is divided into 5 different parts:
- Third-party integrations for getting the data we need
- Product features to build (or outsource)
- Possible future tech stack choices
- Costs associated with different possible MVP solutions
- Further technical investigations needed
Third-party Integrations
A lot of this research consisted of reading the API docs of many social media and event platforms to learn whether they provided all the data we needed. If specific endpoints didn’t provide all the data we needed, could we pull from multiple endpoints and APIs to form a complete picture? For the data not accessible at all via APIs, could we legally build web scrapers to pull the data we needed - with each member’s permission.
Product Features to Build (or outsource)
A lot of the features outlined here were heavily influenced by the prototype we created. In addition to those high level user-focused features, other features outlined here include things like authentication, stripe integration for payments, member application system, user profiles, and a matching algorithm to match members of the community based on interest and proximity to one another.
Possible future tech stack choices
The tech stack suggestion is based on thoughtbot’s standards and is therefore opinionated. It encompasses the knowledge accumulated by many different developers at thoughtbot over many years. It suggests what we think are sensible tooling to solve these types of problems. Some of these suggestions include using Postgresql as a database, Ruby on Rails as the web application framework, and AWS or Heroku for application hosting.
Costs associated with different possible MVP solutions
When listing out the different product features to build, it’s important to keep the MVP in mind. The goal is to get a product in the hands of our early adopters as quickly as possible, get feedback, and iterate. Although speed isn’t always necessarily tied to effort, to move as quickly as possible we usually have to ask ourselves “What’s the minimum we can do to get this working?”. One of the core features we identified that ties into our unique value proposition is the ability to match members of the community with each other based on their interests and proximity to one another. There’s more than one avenue we can take for this feature.
- We can spend a significant amount of time and effort thinking about what a matching algorithm should look like, then spending developer hours to build it.
- We can also start out by having real humans read the profiles of members in a particular area and manually match people themselves. To the end-user, they’ll never know the difference, but it’ll get us up and running quickly and the cost associated with this method is significantly lower than building a fancy algorithm. This also has the added benefit of learning from our experience matching people so that we when we do actually build an algorithm, it’ll be something great.
Further technical investigations needed
This part of the document outlines questions that arose during the research phase of building this document. Questions that involve deep dives into open-source technologies to ensure they do what we need, third-party integrations and their associated costs, how exactly the matching algorithm should behave, and things to consider when building this algorithm so that no unconscious biases or stereotypes are encoded within it.
This technical analysis serves as a starting point for developers and should behave like a living document that encourages dialogue as to what to build and what to leave out.
What I learned
This project was my first introduction to design sprints, thinking like a product designer, and putting myself in the shoes of a founding member of a company. Most of this experience was new to me and, therefore, a great learning experience.
One of the biggest learning curves of this experience was to think of my firmly ingrained beliefs as assumptions instead. This awareness forced me to realize that many of my beliefs held with strong conviction are really just assumptions I was making based on past experience. The brain is wired to do this unconsciously, and it actually is very beneficial in certain contexts. When thinking of solving problems for people in which I do not fit the target persona, however, this can cause harm and lead us down the wrong path.
Exercising this awareness takes practice! At first, it can be difficult to take a belief you hold as fact and have the awareness that perhaps it should be labeled as an assumption that requires validation. I learned that to make this easier, having a system in place to test your assumptions is crucial. In our case, these tests took on the form of user interviews. Even more difficult at first but just as valuable, is having the awareness to label other people’s beliefs as assumptions in need of validation; especially when you don’t know enough about a subject to label it as such.
I believe this practice can be hugely beneficial in the context of software development and consulting work as well. When working with other developers and building a product, it can be valuable to have awareness of the beliefs we hold that are behind the decisions we make. This can be challenging to do because a lot of the technical decisions we make are based on decisions we’ve repeatedly made in the past that have worked well for us. However, given what I’ve learned, I’d like to challenge other developers to practice reverse-engineering the decisions we make keeping the end-user and product goals in mind. This practice can also hold a lot of value when working collaboratively with clients. Every feature request can become an opportunity to question the assumptions behind them and gather real data to validate those assumptions. This five step process can help:
- Exercise awareness of a specific decision
- Take inventory of the beliefs behind this decision
- Practice labeling these beliefs as unverified-assumptions
- Work on gathering data to validate these assumptions by “interviewing” stakeholders, users of a product, and other people within your organization.
- Use this data to drive your ultimate decisions
Founders Journal
Over to Danyelle for a summary of our Founders’ experience with the incubator program so far:
Reflecting on the whirlwind of the past couple of weeks, one thing really stands out: the creation and testing of our prototype within our community and among potential early adopters.
We’ve been flooded with a ton of data and feedback, which has been incredibly valuable. Engaging directly with our community has given us real insights. It’s easy for founders to get stuck on their own vision, but getting real-world feedback reminds us to focus on solving real problems. It’s been exciting to see people’s reactions to our first prototype and to really put our unique value proposition to the test. We’ve identified some early adopters and learned who might not be the best fit.
We’ve also spent time digging into our competitors and identifying gaps in the market, which has been essential for understanding what’s already out there.
The highlights of the week? Hearing people say, “I love this!” and “I’d definitely use this!” or recognizing the need for a community platform like ours. It’s incredibly rewarding to feel like we’re tackling an important problem. In a world where loneliness is on the rise, if we can help solve that and build meaningful relationships, I’m thrilled!
Our team dynamics continue to impress. Everyone is dedicated to the project and works well together. I’m grateful for everyone’s insights and contributions. Being part of a team that’s committed to solving the problem we’re working on is fantastic. It’s a bit sad that this is our last week of regular calls, even though they’re often early in the morning. But I love knowing that we’re all in this together, not just as colleagues, but as stakeholders in our shared mission.
What’s next? We’re excited to package everything up and use it to apply for accelerator programs that can provide funding to further develop and test our prototype. This experience has prepared us well for the intense scrutiny of accelerators, where prototyping and beta testing are taken to the next level. Overall, it’s been an excellent experience, and I would highly recommend it.
What’s Next
Armed with data gathered across more than 50 different user interviews, a strong opportunity framework, and a technical analysis of an MVP product, Womanish is now equipped with a solid foundation to seek funding and grow into the next phase of their journey!
If you are going through a business validation process, or hope to in the future, the Incubator programme may help you as well! We have recently launched the Customer Discovery section of our playbook so that you can tap into our exercises, helping your team find, or re-discover, customer/market/product-fit and support to discover your next best strategic focus.
Liked what you read? We’re also doing weekly livestream broadcasts with the Womanish Incubator team to delve even deeper into goings on in the programme. Follow along on LinkedIn, YouTube and Twitch!
