Running a startup involves making decision after decision after decision, and it has been no different in the first few months of building ribl. The tough part is that for a very early stage startup like us, these decisions are made with small amounts of extremely imperfect information, which makes them difficult. The data that we gather at this early stage doesn’t allow us to draw definitive conclusions; they are directional at very best.
Here are some of the multitude of decisions we’ve had to make in the short time we’ve been building ribl and how we went about making them.
What Are We Going to Build?
In the very early days, when ribl was just a twinkle in our eyes, Jeff, Dan, and I had to think about and agree upon what we were all interested in and what we wanted to build. On top of having different functional skills and experiences – I was the marketer, Jeff and Dan were the programmers – we also had very different industry backgrounds, which made the decision even more difficult. We took a pretty long time to come to a decision and even followed this lengthy process to narrow down our list of potential ideas for our company. If you read to the end of that blog post, you’ll see that we eventually wound up changing our minds – again – after the process was complete!
After we (finally) agreed on a general conceptual direction, we moved on to the customer development process.
Customer Development Decisions
Customer development is a foundational concept of the Lean Startup, which is a framework that helps entrepreneurs to minimize waste and uncertainty when building products and companies. By engaging with and learning about potential customers early and often, you can better understand their needs and problems and build products to address them.
Our initial customer development process involves interviewing potential users in our target segment to learn more about their problems and desires as they relate to local discovery. Our goal for the customer development studies for ribl was to understand:
1, People’s problems with finding out local news, events, and happenings and if current sources, such as social networks, local blogs, newspapers and other sources were sufficient.
- Users’ propensities to share news about what’s happening around them.
- If users had any issues with sharing their location when they post to social networks.
The initial decisions we had to make for the customer development process included:
– How many people should we interview to give us enough direction?
– Who would be the best people to speak with? Who is our target user segment?
– What questions should we ask?
– How many questions should we ask?
– How long should each interview last?
After completing our interviews (we did about 50), we had to analyze the data and determine whether or not the data was enough to validate our hypotheses and allow us to move ahead. Should we speak with more people to see if we can gather more and better data that directs us one way or another? When is enough enough? When should we stop interviewing and start building?
As you can see, there are already plenty of questions to answer and even when they’re addressed, we can never really be sure if we’re right.
Product Development Decisions
After we felt (somewhat) comfortable with our findings from customer interviews, we started the product development process, which involved many, many different decisions to make.
Feature Brainstorm and Prioritization
The first thing we did was list every possible feature that we could think of in a tool called Redmine, a project management and issue tracking software application. We used findings from our customer development process to brainstorm as many “user stories” – features captured from an end-user perspective – as we could generate.
Then came our first product decision – which user stories are of the highest priority and on which we should focus first? Some were obviously higher priority, while others demanded more debate. The key here is understanding what features and characteristics of the product are absolutely essential, and to defer the non-imperative components to a later date.
We took these most important features and grouped them into two-week development sprints. At the end of these sprints, these features would be fully designed, built, and implemented in our app.
Feature Design
Once we agreed upon which initial features were important enough to include in the sprint, we discussed how each of these should be implemented. We asked ourselves:
- What’s the simplest way for the user to achieve the specific task?
- What should each screen look like?
- How should the user flow from one screen to another to achieve said task or transition from one task to another?
- How do other popular apps implement these features (a.k.a. benchmarking)?
During this stage, we drew mockups on paper and used a wireframing tool called Mockflow to portray users’ potential interactions with our app. Sometimes we’d instantly agree on how the feature should be implemented. Other times we would disagree and have to further investigate the best option by garnering additional user feedback and adjusting our designs.
We repeated this process until we all fully agreed on the best way to implement each feature.
Feature Development
After agreeing upon the designs, Jeff and Dan would then program the features and incorporate them into the mobile application. We would then test the features both internally and with users to decide if the interactions worked well and helped the user achieve the desired tasks easily. If not, we would pinpoint and discuss the issues to determine the necessary improvements.
Again, these were gut-feeling decisions, made with minimum amounts of imperfect data.
Rinse and Repeat
After each two-week sprint, we would repeat the feature prioritization, design, and development process for the next set of user stories and once again make a plethora of instinctive decisions. While the early-stage product development process is really interesting and exciting, the lack of data never allowed us to be really definitive about our decisions. And plenty more decisions will be made the same way in the future.
Branding Decisions
Because ribl is a consumer mobile application, recognizable logos and visuals and strong branding are important, and we spent a good amount of time discussing and debating our name and logo.
We had to determine:
- What is a short, engaging name for our app? We had to consider how easy the name is to pronounce and remember, the availability of website domains, and many other factors.
- What would our logo look like, and what should it represent?
- What colors should we use?
- How should our name and logo tell a consistent and engaging story?
These creative decisions naturally lend themselves to be qualitative and thus reliant on gut feelings. We certainly solicited feedback from friends and family, and ultimately decided on the name “ribl” and a frog as our logo:
If you’re curious why, stay tuned, as I’m going to write about it in a future blog post!
Company Organization Decisions
While we’ve been primarily focused on customer research, product development, and branding, we’ve also taken time to talk about our roles within the company and how our organization should be structured. We’ve thought about:
What our equity splits would be. While this can many times be a contentious debate, it went relatively smoothly for us. We certainly had spirited conversations where we advocated for more equity commensurate to our value to the company, but we were able to come to an agreement quickly and harmlessly.
What our roles and titles would be. While our functional roles were pretty clear from the start, we’ve discussed our roles and responsibilities but deferred giving ourselves titles like CEO, CTO, CMO, and others. Once we launch our product and grow the company, we’ll have a better idea who is a stronger fit for these defined roles.
There are plenty of other organizational and administrative decisions – such as how much cash we each should invest to operate the company and how we should incorporate – that we’ll need to make in the near future. For now, we’ll table those to focus on developing and marketing the product.
Conclusion
As you can see, there are plenty of important decisions we had to make in our short time working on ribl, and many more to come. Many of these decisions were made with limited amounts of data, so we had to depend on our instincts and gut feelings to come to conclusions. Only time – and more data – will tell us if the decisions we’ve made in our early stages are correct.
What are your thoughts about our decisions? Please let us know in the comments.
We’re launching our beta for Android early next week and are looking for participants! Please email me at mike@ribl.co if you’re interested in helping out, or visit ribl.co to sign up for our mailing list.
Image credit: CC by Wonderlane
