If you’re working on something new, there are so many directions your work and product can take.
The biggest risk is that you build something that is hard to explain and no one wants.
A good process minimizes this risk. Helping you move in the direction of building something people want.
To build June, me and my cofounder Enzo used a very systematic approach. We decided to shared it as you might find useful.
We hope that It will help you build something amazing
As we followed this process to build June, we’ll use our answers to each section as an example. To use his framework you can make a copy of this template ⚡️
What to build
Narrow down your focus to something you love or that would help people you have empathy for.
We want to build analytics software.
Almost a year ago me and Enzo were talking about starting a business together.
After discussions about who we like talking to we realised we love those who build new things.
Analytics software enables these people to build better things.
So for the next 10 years we decided to narrow our focus to become the best in the world at product analytics.
Problems with the current solutions
Find a way to get some conversations going with your target audience.
To learn what we should build first we started from our personal experience. We used our experience to draft a User Research template (you can find it here).
We then used our template (with many variations) to run almost 100 user interviews with Product people (from leaders to individual contributors) at the best companies in the world.
We then collected all of the pain points people talked about in a map:
Looking back we feel this was the first validation we worked on something meaningful. Setting up interviews with product teams was extremely easy. They were both excited and pro active in sharing their main problems with their analytics setup.
Insights
Make some assumptions based on your conversations
The common themes, together with our intuition helped us pick the main problems we want to tackle:
- Data is not reliable and opaque
- “I am not independent in my analysis”
- It’s hard to understand user behaviours
The second order effects of this are that:
- Analysis gets overseen
- People don’t know what they’re tracking and if the numbers are right
How might we
Dream about possible solutions you can build
After collecting some insights it’s time to come up with a couple of options of things to build.
The first idea was to expand on the Figma extension we had built as it had a thousand users.
The second idea we had was more of an end to end experience:
What if we built an easy to understand product, that allows product managers to answer their most common questions independently?
Requirements
Make sure that what you build tests your assumptions
Our solution has to be:
- Easy to adopt
- Transparent with the data
- Friendly and approachable even with no training (non technical people have to be able to gain meaningful insights)
Rules of the universe
Define some rules that can make decisions for you
Once you defined your requirements — you can define some guiding principles for your product development
A Principle is a strong opinion that is used to make decisions in a fast and consistent way.
These principles then evolved into the Rules of the Universe of our product.
- No black boxes: Data can be visualized and transformed in an invidual and bulk way from the UI
- The steps to go from measurement to some action are streamlined: The product is built around how the team works, not the other way around.
- Optimise for the most common question not the most complex one: Optimise for speed and ease of use of the happy path
- Guarantee trust in data: Be conservative and aim for quality over quantity in both data collection and analysis
- Context specific over generic use cases: Optimise for the context over the method of analysis. eg. Build tools to measure signup activation, not tools to visualize a sequence of events that is triggered in your signup flow.
Positioning
Overlap your product with a possible market.
Your product has to be a good fit for someone, it has to serve a market. June is built for non technical product managers.
June is the simplest product analytics solution. We answer the most common questions product teams ask themselves (or should be asking).
- Do you have product market fit?
- How is the latest feature launch going?
- Is the increased discoverability of this feature increasing adoption?
- Who are your most successful users?
Prototyping
Turn your ideas into something real.
The next step after positioning the product is turning it into either some mockups, a principle project or a frontend only prototype.
The idea here is to see concretely the look and feel of the app.
We used high level mockups to sketch the main flows within our product.
We then made high fidelity designs to get people around us excited and to start coding with some clear ideas in mind.
Scoping
Decide what corners you’ll cut.
Once you have a clear idea of where you’re going — you can take a step back — and pick the smallest set of features that makes a lovable product.
You have to be ruthless in this effort. If after finishing this exercise everyone in your team isn’t in tears and embarrassed of the result then you probably didn’t cut enough.
The idea here is to set a deliberately ambitious deadline of something like 2 weeks to get to something that works end to end.
Scoping as an ongoing process. It’s a process that sequences the work in a way that is optimised for discovery.
We recalibrate our roadmap week by week on Mondays, to always work to answer our biggest open questions.
Building
Make it happen.
This part is the most straightforward, make small bets to get to some early wins, build momentum.
We started with a cupcake, but are working towards a wedding cake.
All this is hard work though… maybe you could help with some extra hands.
If you think you’d enjoy working with us let’s get to know each other..
