Let this sink in: 9 out of 10 startups fail. Among the most common reasons cited by company founders for these failures is that they didn’t have the right team.
What do you suppose are the underlying reasons that a team may not be right?
As a veteran project manager turned startup marketer, I’ve learned that the reason teams made up of highly intelligent and capable individuals fail, more than any other reason, is because of poor communication. Indeed, according to the Project Management Institute (PMI), ineffective communication can be attributed to 56% of failed projects.“Teams that fail, fail to listen to each other.”
The Build–Measure–Learn loop emphasizes speed as a critical ingredient to product development. Often a focus on speed causes teams to devolve into a group of individuals focused on their own contributions rather than collaboration. This sort of myopic approach may yield a functional product—but it rarely yields a viable product.
Collaborative teams that listen to each other—and to their prospective customers—are more prone to create MVPs that are functional, reliable, usable, and emotive.
So then how can teams be intentional about collaborating? I’m so glad you asked…
Start by (and always be) learning—together
Most product teams have an idea and want to build something straight away. That energy is fantastic, but lean methodologies tell us that the purpose of early iterations is to learn as much as possible as quickly as possible. The goal is to test marketability of the idea in order to determine if you’re on to something. 4 ways to do that:
- User research. Understanding user behaviors, needs, and motivations is an essential first step to building a product that people want (or need). There are many user research techniques: interviews, card sorting, surveys, etc. Often designers are responsible for this type of research, but including others in the selection and execution of a research project will help create a shared understanding of the problem your team is solving.
- Personas. These abstracted customer archetypes are common deliverables for most product teams. Their focus may vary from team to team or product to product: understanding demographics may be important, or perhaps psychographics or something like technical skills may be more appropriate. One benefit of creating personas is an increased sense of empathy for users. Proto-personas are a great start because everyone can get in on the action.
- Paper prototyping. Some people argue that paper prototypes are a waste of time. But naysayers, agree that they are appropriate for early stages of the design process. Using paper and markers levels the playing field, allowing the whole team to participate in a conversation about possible UI solutions to the problems you identify in research. This also sets a great precedent for future design critiques.
- Define success. “How would you feel if you could no longer use [product]?” According to Sean Ellis, co-founder of Qualaroo, if 40% of customers answer “very disappointed” to that question then congratulations are in order. You have found product-market fit! Aligning on the definition of done can quiet arguments before they start, keeping team spirit high.
Build something collaboratively
Everyone involved in creating a product is a ‘maker’ of some kind. Each team member may specialize in a particular discipline (design, development, analytics or management), but that doesn’t preclude anyone from contributing to the entire process. Before you dive in and start designing your next mockup or coding a function, consider taking a collaborative approach. And remember, providing honest feedback to each other during these activities is one of the best things you can do for each other.
- Design mockups. Whether your tool of choice is Sketch or Photoshop, high-fidelity comps are subject to the an inordinate amount of subjective critique. To avoid a bevy of ungrounded feedback restate goals at the beginning of any critique and show prototypes (in InVision!) whenever possible. To avoid groupthink, participants should write down their feedback first and then discuss.
- Pair program. So not everyone on your team is able to code in Ruby. That doesn’t mean you can’t find for opportunities to make decisions in real time, together. Fine-tuning the easing of a CSS transition, choosing a menu configuration, or writing headlines are all activities are all great times to stop, collaborate, and listen.
- Integrate analytics. Before releasing any product into the wild be certain that goals are mutually agreed upon and key events are tracked. Having analytics in place will give your team important information with which to make decisions about future features to help achieve product-market fit or scale your business. Using an analytics API like Segment can make everyone’s job a little easier because it simplifies implementation and provides turnkey access to other tools.
- Quality assurance. Testing is an essential part of building great software. Sure, developers writing unit tests can be helpful, and automation speeds things up. But nothing can replace manual testing. Each person on the team shares responsibility for what gets shipped. Everyone is a quality ambassador.
Measure how you did, collectively
Even the most data-driven teams have to make a lot of assumptions and guesses to ship a product. The best way to mitigate missteps is to assess the efficacy of those decisions along the way. 2 ways to do that:
- Usability testing. One of the best ways to improve a product is to get feedback from representative users—millennials may understand your product better than a senior business executive. Online user testing services make problem discovery a whole lot easier by making thousands of test subjects accessible to you, so those problems can be remedied before releasing the product to the wild.
- Split tests. Eliminate lengthy debates about which design solution is best by A/B testing. Optimizely makes it easy to collaborate on split tests because it makes it easy to explore many ideas. Everyone gets a say, and the best-performing option wins. No egos, just results.
- SQL. Advanced analytics is one of the best methods of identifying cause:effect relationships between the customer experience and business performance. Sit together to ask questions, write queries, and find answers. You’ll be amazed at what you can unearth through collaborative analysis.
Iterate, because “good enough” never is
Teams must work together to incorporate validated learning into each and every aspect of their work. As the marketplace changes, products and marketing should be modified to better meet customer needs. Here are a couple of activities your team can do to inform the next iteration of your product.
- Net promoter score. “Would you recommend this product to a friend or colleague?” That simple question is an invaluable indicator. Knowing which customers are promoters and detractors helps marketers generate case studies and product teams better understand their ideal customer. I’ve found Delighted to be a great tool to capture this information.
- Cohort analysis. By segmenting users into different groups (cohorts), teams can run sophisticated models that prove performance of campaigns or product UI changes. Teams should collaborate to articulate their hypotheses before running experiments and also rally around the results to generate insights.
Collaboration is the key
In a Harvard Business Review article, Robert J. Thomas of Accenture Institute for High Performance wrote, “What makes collaboration distinct, and so powerful, are the conditions that call it forth. Specifically, collaboration works best when people work together on problems that:
- Don’t have an obvious solution: the problem addressed is not a routine one
- Lack structure: there isn’t always a familiar process to follow
- Require collective volition: some sort of sharing is needed but cannot be mandated”
That said, I’m sure you can see that product design is a ripe opportunity for collaboration.
Next time you tackle a project, I hope you’ll consider who else could be involved. Your results will be better for it.