The first 6 months of product development at Orelo until launch: Tradeoffs and frameworks
I’m writing this piece to document some of the processes/frameworks we used to build Orelo from an idea in a business plan into a real world app. I’ll be focusing on the product/tech aspect of these last six months, but keep in mind that this is not the whole picture as our efforts in other fronts like finance, CX, Editorial and Brands were as important in order to make it a viable business.
Here’s an attempt to share what we did, where we focused and some tradeoffs we took.
Understand your users: Write stories from their perspective
First, we’ve defined all of our users’ stories. Who are your users? What will they do in your application? Write the stories from their perspective. Don’t filter anything just yet. Get everything written down so you can reference it later (to yourself and to other members in your team). We’ve written 172 stories that would be acted by our listeners, podcast owners, brand owners and admin/account managers.
Defining the MVP boundaries: Prioritize based on your main value propositions
There were two main problems we’re trying to solve and based on those we’ve decided what we would build first:
Problem: Podcast Creators are not valued by the industry. — > Podcast creators should be able to receive money from their streams and receive donations from their listeners.
Problem: Discovering new podcast content is hard, mostly by word-of-mouth. — > Listeners should be able to find and listen to new and interesting content easily.
Based on those two main focuses of action, we’ve prioritized our stories into two categories: “MVP” (Minimum Viable Product) or “Later”. MVP stories would be the absolute minimum necessary for the launch, which means that we would delay launch if they were not ready. Prioritizing means saying NO to a lot of things and requires lots of courage. At first, everything looks “the absolute minimum”. You don’t want to launch a product knowing lots of users will miss a given feature (because you love them). But the idea is that by putting your product in their hands sooner than later, you will have a better understanding of what they really want. We’ve tagged 87 users stories as “MVP”.
High Risk premisses: Validate them first
Before diving down into further planning, we’ve found it wise to stop a while to validate our two riskier premises:
- How to make all podcasts/episodes available on our platform (tech challenge)
- Would it be possible to direct part of our subscription directly to the podcast owner without incurring double taxation (split payment)?
We’ve answered those questions by creating a proof-of-concept scraping service that would aggregate more than 700k podcasts worldwide (and sync its new episodes automatically) and by choosing ahead of time our payments platform partner.
Huge time-savers: Wireframes and Domain Driven Design
Together with the writing down of user stories, this is where I feel we’ve saved a ton of time by iterating in our product UX (User Experience) and architecture before a single line of code was written.
We’ve created wireframes for every screen flow, every empty state and all fail cases we could think of. The empty states and the fail cases were essential so we could spot dead ends in our UX flows and think of ways of pointing the user in the right direction. Many user stories were added at this point. We’ve used diagrams.net (former draw.io) out of familiarity and speed of prototyping, since it’s intuitive enough that anyone on the team could help out when necessary.
It’s worth pointing out that if we had a dedicated designer we’d probably go with Figma since it could also make the wireframes navigable.
Domain Driven Design also helped us to find blind spots in our UX. By defining our domains and mapping their relationships we were able to have a visual map of our business logics and use cases.
Kick off development: Start with what matters
When selecting what to build first, we were prioritizing stories or group of stories based on three frameworks:
1. Main Value Propositions over complementary
2. High Risk over Low Risk
3. Big over small
It was really clear for us that we should start by building the stories related to the audio player. It was really high up in all three of those items: It’s what’s going to generate the most value to our listeners and what they will use 100% of the time they interact with the app, it was high risk for us since we still had many questions about how it would work (Can we give listeners a good experience even if we’re not hosting the episodes? Can we make sliding and skipping of the timeline performatic?) and it was huge in terms of the amount of work comparatively with all other stories. User login, user profiles, social features, podcasts and episode listings could all come later.
Aiming to get 80% right
The fine tuning (last 20%) of features is sometimes more costly, in terms of development time, than the core of the feature (first 80%). Knowing that our plan would change and evolve, we didn’t try to get everything right on v1 of every feature. It would be too risky to assume we’ve made the perfect plan on our first attempt and that nothing would change. Guess what? It changed. We’ve had to totally change our approach of how we’re building the player internally in order to accommodate the player controls via notifications. I was really happy that we didn’t make the V1 of the player perfect the first time.
Empowering the team: Admin and Continuous Integration
Trust in the tech team is built and kept when people have all the information they feel they need, when they are part of the creation process and when they have power to solve problems on their own.
We’ve set up Continuous Integration right after our “initial commit” so the whole team could participate in the development process. In the beginning we had issues with our apple account and sometimes frontend and backend weren’t synced, but when we managed to fix those issues, most new users’ stories pushed into our staging branch were automatically deployed to everyone’s phones so we could get live feedback from the team. As a counter example, watch this youtube clip from the Startup.com documentary where the CEO tests it’s product for the first time 4 days before launching and finds out it doesn’t work (it’s hilariously painful).
We’ve also prioritized building our admin console where the team is able to manage our original podcasts series, add podcasts feeds manually, manage users and even reset their users (staging environment only) so they can experience a fresh sign up again and again. It’s hard to prioritize building an admin from day 0 since it doesn’t generate value to the end user right away and you can live off with scripts and straight to DB writes/queries for the first months, but in our experience the tradeoff was worth it! The team is empowered and tech is focusing on important things.
Conclusion
Orelo is now launched and you can know more about us at https://orelo.audio.
Overall I feel really happy with this process we’ve used and would probably use it again if building something from scratch in the future if conditions were similar. This is what we did and what made sense for our context of business model, product, team, financing, etc. Change this context and we’d probably have taken different sides on our tradeoffs.
Special thanks to our CEO Luiz Felipe Marques who was supportive and resourceful during those hard tradeoffs and to our Software Architect Pedro Calderon for the beautiful and elegant work done designing our models and APIs.
References
Getting Real: The Smarter, Faster, Easier Way to Build a Web Application by 37 Signals
