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.
Related: Who should conduct and observe design research?
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. Here are 4 great 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 regardless of what’s said by the naysayers, most designers 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. Learn more about low-fidelity vs. high-fidelity prototyping.
- 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.
Related: A quick guide to design research
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 Studio, Sketch, or Photoshop, high-fidelity comps are subject to an inordinate amount of subjective critique. To avoid a bevy of ungrounded feedback, restate goals at the beginning of any critique and show prototypes (preferably 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 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 that provide opportunities 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 that could lead to better product-market fit. 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. Here are three great 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 much easier by making thousands of test subjects accessible to you. They’ll help you find problems quickly so that they can be remedied before releasing your product into 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 by making it easy to explore many ideas. Everyone gets a say, and the best-performing option wins. No egos, just results.
- SQL. Using 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?” This simple question is an invaluable indicator. Knowing which customers are promoters and which are detractors can help marketers generate case studies and help product teams better understand their ideal customer. I’ve found Delighted to be a great tool to capture this kind of 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.
“Iterate, because ‘good enough’ never is.”
Related: Your team needs to make user research a habit
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.
We’re big fans of using Freehand to collaborate within a team. Freehand is a tool that helps you do it all from wireframing to creative exploration, presenting to collaboration. Give it a try and let us know what you think!
Brent is a veteran team leader who is fascinated by the intersection of data, design, and content. New recipes and saisons fill much of his time.