6 months ago we started a new team with a new mission and big dreams. We secured resources to give the mission a proper chance to go through Product discovery, a luxury in a fast pace startup like Buzzvil. Promising, right? Well, in this article I want to talk about all the things that didn’t go as planned, and there are plenty! Let’s go through 4 major ones, with a grain of salt.

(Mis-)Alignment

When you start a new mission, the first step is to clearly define what this new team will work on and what are the objectives. And we did. But see, even with a written mission objective, misinterpretation and misalignment happened right after we started. What we did wrong here was to not involve all the stakeholders in the mission’s definition. The involvement from the start wasn’t complete, all actors weren’t actually aware and implicated in this new team. Small gaps became very fast, large cracks in our alignment and we had to roll back to the start, in order to re-align everyone, from the internal actors (mission members) to the external ones (stakeholders).

Takeaways

Build a bulletproof alignment from the start, involving everyone that has stakes in that project. A good format for this would be to have an alignment workshop where everyone participates in the making of a product field, for instance. If everyone is here and collegially decides on the goal of this new mission, it will naturally enforce a clear direction understood by everyone.

Let’s do customer interviews tomorrow

It isn’t easy to find customers to interview in a B2B business. It requires time and networking. So even if we knew that this was crucial, we delayed to “prepare ourselves” more. We created dynamic interview sheets, did lots of market research, then did more research. But didn’t schedule any interviews. The team also fell short of actually reaching out to customers. We started this mission as a team of 2, one PM/Designer and one Engineer. But none of us had the related network to reach out to customers. Among our stakeholders are our CEO, John, and CBO, Steve. They helped us move forward, but the simple fact that these actors aren’t inside our team made the whole process very slow and it took us months prior to having our first interviews. I do think that even in a best practice case, it would take weeks to get a first interview scheduled. But in our case, things got delayed out of proportion and our team suffered from this as we couldn’t move forward without these precious insights.

Takeaways

Never ever, ever-ever-ever delay customer interviews while in the product discovery process. Do it today. Particularly for a B2B product, getting a customer to agree to an interview can take time. So start with that, contact potential customers, even if you don’t have anything ready for it yet. You’ll have time to prepare.

We have super-powers and can multitask

Nope. No magic here. I was the first to pile up responsibilities, being in charge of this new mission team and also leading the Design team. On top of that, frequently supporting design works for teams with no design resources. You can use all the tricks you know, Product discovery takes time. Actually, more than I could afford even at full-time. But I anyway decided to (or had to?) keep my previous responsibilities. The result is that delays occurred all along the way because the context switch had a hefty cost on my resources. Also because people tend to prioritize what’s impacting others first, or at least I do. Today I still have these multiple responsibilities, and I know that this is a problem. But the team grew in numbers and it is now more manageable (not an excuse, more like a fact).

Takeaways

Product discovery requires incredible focus and dedication. Particularly when there is nothing done before when you need to start a completely new product or focus on a new customer segment. Securing this focus is an absolute priority to ensure an efficient discovery phase. We didn’t and it took us more time than what we initially planned, actually nearly twice the time we first allocated ourselves.

Believing in other data than your own

We made this mistake a couple of times. While researching, and after struggling to find market insights for some time, it is always tempting to believe in a report given by another company. But in all cases, after finding more compelling technics, we found out that the given data wasn’t accurate or even completely wrong. Getting the data wrong from the start alters your assumptions and eventually makes you draw false hypothesis. Hypotheses that could lead some of your product directions later on…

Takeaways

Always, always trust YODA (Your Own DAta)! And try to rely on external sources the least possible. Obviously, it is difficult to completely strikethrough every source of insights you can find on the Web, but at least put them in italic, and try to verify them as soon as this is possible. And of course, never entrust these insights to make product or business decisions!

Bonus: things we’ve done right!

We’ve made many things wrong, but we also did a few things correctly.

• Do not spend time with tools. Drop Jira and all the other management tools. Discovery is a demanding process, but that doesn’t require tons of preparation and management. Keep it light, we used Figjam for pretty much everything!
• Forget about your cubicle! Discovery is the time to chat, debate and move forward as a group. Plan frequent ideation/brainstorming sessions and let the compulsiveness of your group do the rest!
• Forget about specialty! Well, not completely, of course, but during Discovery, engineers won’t code (or maybe for the sake of an experiment), PMs won’t manage, and Designers might design, but for conceptual purposes only. Be the expert you are, but participate in this product discovery as a member of your mission. Let everyone be curious about everything!
• Onboard new members closely. Starting a new mission isn’t easy. Joining a new mission after it just started, before knowing what we would build is super hard. So we took all the necessary time to ensure that our new friends know exactly what we are trying to do and where we are at.

Re…tro…spect

All the mistakes we’ve made were discovered soon enough through frequent retrospectives (on a monthly basis, plus punctually when we could identify something’s really wrong). So we turned these mistakes into insights and lessons. We obviously lost time, but we were also aware that this might happen from the start, as all of us were new to product discovery. Our story showcases the importance of running frequent retrospectives. There is absolutely nothing wrong with making mistakes, as long as you can identify them fast and learn from them. If you don’t, this will have long-lasting consequences on your team’s performance, and ultimately on your product too.