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 , and my cofounder used a very systematic approach. We decided to shared it as you might find useful. June me Enzo 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 we had built as it had a thousand users. Figma extension 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 of our product. Rules of the Universe Data can be visualized and transformed in an invidual and bulk way from the UI No black boxes: The product is built around how the team works, not the other way around. The steps to go from measurement to some action are streamlined: Optimise for speed and ease of use of the happy path Optimise for the most common question not the most complex one: Be conservative and aim for quality over quantity in both data collection and analysis Guarantee trust in data: 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. Context specific over generic use cases: 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 , but are working towards a wedding cake. started with a cupcake 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.. Schedule a 15 minute chat to meet us here !
