metalab logo
February 11, 2020
Meta

Hindsight is 2020: Things we learned the hard way in 2019

In case the timing of this post didn’t make it obvious enough, we aren’t big on New Year’s Resolutions around here. But with over 50 projects completed in 2019 and a rapidly growing team, we know better than to breeze forward without reflecting on the lessons that got us here. This is a practice we try to incorporate on a regular basis, and the honesty in our project retros and regular town halls often reveal some of our most valuable opportunities for improvement.

So in lieu of yet another Instagram-worthy highlight reel of 2019’s shiniest wins, here’s a quick rundown of our messier moments from last year (and the advice we wish we’d had back then).

One of our Design Directors on why design doesn’t always age well

metablog

The TL;DR

It wasn’t until halfway through wireframing on a recent project when I realized that I’d neglected to consider what is arguably one of the most important variables in the design of any product: the element of time.

My team and I were on a brainstorming call, and I asked, “What would this look like with completely different content?” From there, the can of worms was open and we saw how unsuccessfully our current execution would withstand the test of time. Our wireframes were designed around very specific—and very minimal—content, but the experience would become extremely jarring if more content was added and changed over time. And it wasn’t just a content problem. There was something inherently problematic about assessing our designs in a state-by-state context since so much of the user experience happened in the transitions that connect those dots.

We’d overlooked the fact that the connective tissue—the transitions, the loading or offline states, the interacted states—reveal a lot about how to accommodate a user’s needs as they move through time. It might sound obvious, but it’s easy to forget that designing for the here and now shouldn’t preclude you from leaving flexibility for future adaptations.

My advice?

No matter how intuitive your layout or how pleasing your color palette, your design won’t be of much use to anyone if it isn’t flexible enough to accommodate a handful of other realities in addition to the one you’re currently facing. You don’t need any super fancy techniques or methodologies to address this, either.

Start by asking if your product’s value proposition changes with different contexts and over time. What can you deduce from previous requirements that might help you predict what will be needed in the future? Look at ideas you’ve previously abandoned and try to argue them back into play.

Lastly, give new prototyping tools a shot; the more fluidity and interactivity they offer, the less dependent we become on states to design for the experience continuum.

Our Director of People Ops on why representation matters

metablog

The TL;DR

The thriving culture and smiling faces you see on our website aren’t just for show. We try to involve our employees in important decisions, encourage dialogue, and put people first. Generally speaking, we have a genuinely happy group of people roaming the proverbial halls of MetaLab as a result. But for a company that prides itself on its remote culture and global perspective, our lack of diversity is a problem.

Everyone deserves to be represented in the spaces in which they live and work.

It's a problem not just at MetaLab, but in our industry as a whole. First and foremost, it's a people issue: everyone deserves to be represented in the spaces in which they live and work. Secondly, it's a business issue: when underrepresentation goes unchecked, the quality of the work suffers. We can’t responsibly build products that serve billions of people from all walks of life if our teams aren’t just as diverse. To do our jobs as people and product designers, we have to actively invest in a community of equal representation, access, and inclusion within MetaLab and beyond.

My team and I spent 2019 trying to be part of the solution, starting with a focus on hiring. We hosted events and attended workshops and training sessions. We removed candidate identifiers from our screening process to reduce unconscious bias and launched a new Careers page to reflect a company where anyone could feel like they belong.

Over the course of last year, our good intentions progressed into baby steps forward. It's something, but we’ve got more progress to make. If we've learned anything, it's that taking a top-down approach will move things farther, faster. So this year, we're working with professionals to integrate diversity, equity, and inclusion into all aspects of our company for a more meaningful impact.

My advice?

Look in the mirror and be honest and clear about where you are and where you want to go. Ask for help, and ensure that it’s a priority at an executive and management level. Then, take small, consistent steps towards implementing change. Hold yourself accountable along the way, but don’t shortchange yourself on the self-compassion you’ll need to overcome the reality of how far you have to go. Most importantly, ensure that these efforts are a transparent collaboration all the way through and give every person at your organization a supportive seat at the table.

Our VP of Partnerships on the value of turning down clients

Photo of Luke Des Cotes, MetaLab's VP of Partnerships

The TL;DR

The folks in the tools are what make our business what it is. At the end of the day, our model is pretty simple: we hire the best people in the world to do incredible work with great clients. Rinse and repeat. Our employees could work just about anywhere in the world, but they choose to work at MetaLab.

That means it's my team’s job to make sure MetaLab is a compelling place to be through the projects we bring in the door. Easy to preach, sure. It’s a whole lot harder when that means leaving millions of dollars and interesting work on the table because something about a client just doesn’t feel right.

We’re relationships people, so we feed off of energy, good or bad. When it’s good, it’s really cool to see the positive impact that it has on the work. When it’s bad, we take it seriously and do something about it. We’ve had enough very good and very bad client relationships to know that when the team suffers, the products suffer, and nobody walks away getting what they came for.

This past year alone, we ended up saying “No, thanks” to hundreds of projects in the name of protecting our team. The ones that keep me up at night are the few that slipped through the cracks, like the two clients that we had to part ways with and the handful of others we should have ended things with much sooner. A bad apple spoils the whole barrel and when our team feels tired, uninspired and frustrated as a result, that’s (partially) on me.

My advice

Take your time and then trust your gut, even (and sometimes especially) when clients are in a rush to get things signed off. Don't hesitate to slow things down, book that extra call or ask to meet in person before agreeing on contracts. The same goes for stress testing anything that doesn't feel right throughout the process—make a point of challenging them and seeing what happens. Regardless of how big the name or how deep the budget, these relationships are two-way streets. Like any good relationship, they take time and work to cultivate, and the early interactions are typically windows into what to expect down the road.

One of our Engineering Directors on why it’s good to get it wrong

metablog

The TL;DR

We have a very high bar for shipping functional, polished products, so the better we can integrate our design and engineering teams, the better the quality of the end result. Where many traditional teams usually take a waterfall approach to their development phases, I spent 2019 experimenting with different methodologies to see if I could set the quality bar even higher, faster.

On estimation calls, I’d push to get development started on projects as early as possible. This would allow the team to start looking under rocks, asking questions, and laying a foundation for the rest of the product architecture. In some cases, this worked really well and made projects a million times better. Other times, it was obvious that we’d pushed it too far.

How could development be expected to build a product that hadn’t been designed yet? How could designers be expected to map out the data flow when they didn’t yet have the actual data? Both questions were equally valid and frustrating, so we had to get creative with staffing projects to keep things moving forward. Still, what we’ve gotten from these experiments far outweighs the perceived safety of a singular approach to engineering. As the classic “waterfall vs. agile” debate rages on, we’re focused on building an engineering team and schedule that maps to each project’s unique needs.

My advice?

Don't be afraid to tinker with the status quo. You might break some things in the process, but you’ll learn a lot more in veering “off-course” than you might have otherwise and your solutions will be even more foolproof as a result. But before you start taking things apart or moving in an unconventional direction, make sure you’re clear about your team’s non-negotiables.

I managed to feverishly champion finding ways to be 10% better while also reiterating the need for everything to be delivered on time and on budget. Whenever you run a new experiment, over-communication (both internally and with stakeholders) is the key to protecting the integrity of the product during the trial and error that comes along with trying something new.

Our COO on why imposter syndrome is worth talking about

metablog

The TL;DR

“What do you do at MetaLab?” The question wasn’t out of line or invasive for a networking event, but it didn’t make answering it any easier. Like I had done so many times before, I found myself sharing that I “worked in Operations” rather than telling people I was the COO of MetaLab. I’m immensely proud of where I work and the teams I get to lead, but sometimes I'm still uncomfortable with the title that comes with it. In my mind, broadcasting my C-level role sets me up to fall short of expectations that people might have of what a “good COO” should be. Underpromise and overdeliver, right?

It wasn’t until well into my career that I had a name for the healthy dose of self-doubt I’d carried with me over the years: imposter syndrome. I can tell you from experience that this negative self-talk doesn’t discriminate across skill level, expertise, or any other differentiator. While it’s a mild nuisance for some, it can be debilitating for others. For me, the voice telling me that I could do better makes it hard to celebrate my successes, but it’s also what motivates me to succeed in the first place. As a result, I’ve tried to embrace the ways in which this voice serves me and be more aware of what happens when it starts to get in the way.

My advice?

There are no dumb questions; your curiosity is an investment in your growth.

I find that past performance is a great indicator of the future, so the quickest way to stop thinking you’re falling short is by internalizing any cold, hard evidence to the contrary. If others tell you you’re doing a great job, you probably are (and probably will again). When you need direction, keep in mind that there are no dumb questions; your curiosity is an investment in your growth. For example, I recently joined a project team for a couple of months to gain first-hand product design knowledge to boost my subject-matter confidence (spoiler alert: it worked). Also, stop trying to “fake it ‘til you make it:” I’ve learned that humility and a willingness to learn gets you a lot further.

New and improving

It’s good to talk about these things. And talk and talk. But instead of just waxing poetic about all the things we’ve learned, we’ll be a lot more comfortable when we have tangible changes to point to the next time we sit down to chat. We’re approaching this just like we would any other project: take things week by week, step closer, step back, invite feedback, implement learnings as early and as often as possible, and always, always produce something real in the end.

Wish we’d addressed a different topic, or want us to dig deeper into something that we covered here? That’s what our AMA forum (answersplz@metalab.co) is for. We’re all ears.

From the Survey:
What challenges are you facing today?

Most of our startup founders were primarily concerned with financial budget constraints, prioritization of focusing on the right product features, getting buy-in from stakeholders and investors, and keeping up with the constant changes in the market.

Enterprise leaders had a different challenge, concerned with the ability to get organizational alignment and clarity across complex levels within the organization.

However, the common challenges that both startup founders and enterprise leaders from the majority of our participants were around hitting timelines to ensure speed to market, available resources, and ensuring the product would resonate with customers in today’s market.

PLAN OF ATTACK

User Research

Talking to users to understand their needs, requirements, pain points, and how a product could better enable or change their day-to-day life.

Concept Designs and Prototypes

Establishing the underlying product idea and how it will be expressed visually. This includes ideating and designing the differentiators (more on this later). Then, testing those design prototypes with users to understand their reactions.

Product Market Fit, Vision, and Strategy

Determining a product's value proposition for a given market and understanding the widespread set of customers it might resonate with. Looking at the competitive landscape to identify competition and their strengths and weaknesses. Mapping user needs to business opportunities to create a vision, goals, and objectives that your product will address.

Product Definition

Identifying all the key features needed, high-level design direction, user journeys, and high-level happy path flows. This also determines the conceptual architecture, tools, technologies, and high-level operational needs to bring those key features to life.

Design and Development Sprints

Working in an iterative, sprint-like manner during the product delivery lifecycle. This allows you to focus your efforts in two to three week bursts, designing out key features and moments of the product, testing it out with users, developing those features, performing quality assurance, and then retrospectively learning from the past two weeks to improve.

Go-to Market and Marketing

A go-to-market strategy is a detailed plan for launching a new product or expanding into a new market. This helps you launch your product to the right audience, with the right messaging, at the right time.

From the Survey:
Where would you invest?

In our survey, we asked product leaders where they would invest most heavily in the product cycle. The majority of answers come in with Product Definition, followed by determining Product Market Fit and Strategy. Design and development of the product along with user testing took the middle priorities, and go-to-market and QA took 5th and 6th respectively.

Finding the right focus

Discovery + Solution
Prod
Def
Foundations +
Differentiation

30%

Feature Design
Development + User Testing

60%

Marketing + Growth

10%

30% focused on getting to Product Definition

User Research
Concept Designs and Prototypes
Product Market Fit, Vision and Strategy
Product Definition

We find this is typically the right amount of time to ensure you have an understanding of the opportunity areas and that your product addresses 1) the needs of your target market, 2) has a design and features that are differentiated from competitors, and 3) it will be able to generate your target business goals.

60% in Design, Development and User Testing sprints

The bulk of your efforts should be focused on creating an exceptional user experience for your product. This is where you bring the product to life and test that it resonates with your target audience. You always want to measure to ensure that it meets your needs.

10% of time and efforts towards Go to Market and Marketing.

Once your product is ready for showtime, you need to dedicate time to ensure it will reach your target market. You also want to validate that they understand its value and why they should engage with it.

VAlidators

Do our monetization plans make sense to drive revenue?
Will this resonate with the market?
What is the competitive landscape?
What are the key features that will drive early user adoption?

Differentiators

Domain
Experts

product
blueprint

Now that you have a strategy and your differentiators in place, it’s time to draft the entire product experience into a single document. This is a key step in the product lifecycle called product definition. 

One of the key deliverables that comes out of the product definition is the product blueprint. Your product blueprint allows you to visualize the entire product service on one page. This helps manage its complexity, including the actions and touchpoints of all the actors, key features, technical dependencies, and operational requirements.

Behind the scenes, there are several key assets that power this product blueprint: 

Goals and objectives
Priorities
High-level designs
Definition of key features
User journeys
Technical architecture and plan
Key operational dependencies
High-level roadmap

This view helps to ensure your team is aligned on the critical pieces of success.

That being said, it’s easy to go overboard with product blueprints, so don’t boil the ocean! Focus on the few critical features and components that will make a big impact for your customers.

Remember to trust in yourself and the research that has been done. Your customers don't always know what the right solution is for their wants and needs. That's why it's your job to consider their needs in the context of your product's potential and develop an appropriate blueprint that can scale in the future.

Skilled
Makers

We saw earlier that you’re going to be spending the majority of your time in the product definition/design, testing, and build phases, which means you need a talented team of skilled makers. 

This may seem obvious, but when building the right team with the right chemistry within your budget, there are a lot of factors to consider. How long will it take for the team to gel? Do you stick with who you have? When should you contract vs. hire?

Chemistry is Key to Achieving Velocity

Too often, we see companies spend big budgets hiring a ton of great developers and designers. They throw them onto a project expecting the product will be delivered fast only to find the team isn’t hitting their milestones. Why? 

Teams typically struggle to get going immediately because of differing working styles, personalities, mindsets, and honestly… sometimes ego. That’s why you shouldn’t focus on individual hires but on the team as a whole.

If you have time, budget, and desire to invest in the future culture of your company, you have to invest time to build the team dynamics. We find that it typically takes 4-5 sprints for a team to find its groove — approximately four months, or more.

If you are an early stage startup, and don’t have a lot of time (six months or less), but still want to get a product out there quickly, we recommend hiring a pre-built team of skilled makers who have launched several products together. 

The key takeaway is to not waste all of your time and money hiring. Building a successful team takes time and cycles of members working together to hit their stride. When necessary, augment with experts to help your team grow, add a skill, or just simply to outsource a function. It ultimately comes down to how you want to allocate your resources.

From the Survey:
Hires vs Contractors

Industry leaders we spoke to prioritized Engineering, Product, and Design roles as full time hires (in that order).

Research and Brand functions to be the first specialized roles that could be contracted. There is no one-size-fits-all answer: this could work for those who are racing to build quickly and already have many of their market questions answered, but could cripple a team that is in the opposite situation.

With CEOs and Execs, the most suitable roles for contracting work are Research, Brand & Design.

Accelerators

Don’t reinvent the wheel… and don’t build everything from scratch! Accelerators are existing tools and technologies you can leverage or integrate into your product.

Accelerators enable us to get new products to market faster and enhance our team's capacity to build quality into the development process and focus on solving the most important problems.

There are three main types of accelerators we leverage at MetaLab:

Design and Prototyping Tools

Some of the tools that we use to help accelerate the design process to create and test out designs, concepts, and prototypes with users include Figma, Framer.io, and even Typeform.

Figma: Design Tokens to improve styling and brand consistency in the products we build
Figma: Lokalise integrations for supporting localization in the design process
Chromatic to enable simple VQA workflows in conjunction with Storybook for component libraries and design systems

SAAS Integrations or Cloud Platforms

For development, we use many different tools and platforms on our projects to help accelerate the product development lifecycle and build products that can scale to meet customer demand.  Several of the most popular and impactful integrations and platforms used by our teams include:

The wide range of resources and services offered by Amazon Web Services allow us to architect globally scalable solutions
IaC tools like Terraform Cloud to accelerate the deployment and management of foundational architectures that we see across many different projects
For quickly enabling teams to build and deploy web prototypes and services we’ve come to adopt Vercel and Heroku for ease and simplicity
Microsoft App Center enables us to construct build and deploy workflows across multiple mobile platforms like Apple App Store and Google Play
We leverage a wide range of content management systems that allow us to quickly model data schemas and provide administrative capability including Storyblok, Sanity, Contentful, and others.
Sentry provides our engineering teams with visibility into code quality, error logs, and performance early in the development lifecycle

AI Tools

AI is everywhere these days for a reason. It’s powering brand new ways to get work done and being incorporated into almost every tool we already use to make workflows easier. From content creation to scheduling, we are seeing tools popping up for everything. Here are a few that can help accelerate product development:

Image/Video Generators: Dall-E and MidJourney (image) and Runway (video) are tools allowing for renderings based on a few lines of text as a prompt or by using another image as inspiration. Adobe Photoshop also includes a generative AI that can not only add to an image but help with the editing workflow as well.
Large Language Models: Perhaps the most popular AI tools, LLMs like ChatGPT and Google Bard have a laundry list of useful applications like content generation, researching new topics, generating code, refining copy, and much more. With the right prompts, ChatGPT can also help with generating user stories and epics at the onset of a project.
Interface Design Tools: UIzard, Galileo, and Genius can all help to create UI structures and frameworks to boost design efficiency.

There are important considerations to keep in mind when using any AI tool in a responsible way. Sensitivity of data uploaded into any of these systems and the originality of the content is a big one.

Policies and regulation with AI are still being figured out, so it’s wise to exercise caution when setting guidelines for your product teams. Leverage these tools as inspiration or starting points for copy, as pieces of a larger composite for images, or to get as specific as possible with prompts in order to generate something unique.

Feedback
mechanisms

Product development succeeds when teams develop a culture of continuous learning. This is fueled by rigorous testing, analytics, and strategic iteration during key phases of the product lifecycle.

In the discovery phase, we immerse ourselves in understanding our potential early adopters' needs and motivations (see #validators). Alongside this, we work with clients to think through solid analytics strategies. This step instills a data-centric culture from the start, setting the stage for ongoing learning and adaptation. 

By aligning qualitative user insights with a framework for quantitative data capture, we ensure the product strategy we craft will continually evolve to meet user needs.

As we pivot to the alpha and beta stages, the emphasis turns to iterative improvement. We engage early adopters in testing programs. Their first-hand experiences provides invaluable feedback to detect bugs and potential enhancements. 

This feedback, bolstered by real-time analytics data, drives our evidence-based refinement process, prepping the product to be market-fit.

By investing in this cycle of continuous learning — persistent testing, data-informed analytics, and strategic iteration — we embrace a user-centric ethos in product development. This equips our clients to not just navigate, but also thrive.

When Ravi Mehta (former CPO at Tinder/Product Director at Facebook) was working on the first iteration of his personalized coaching product, he validated it quickly with a paid offering he pieced together with a number of low-code tools.

Leveraging learnings from a community of early adopters, he partnered with MetaLab to help enhance, refine, and evolve the product into the Outpace app.

Outpace launched earlier this year. It provides guided programs for personalized career development designed to level up with the support of a one-on-one AI coach.

Revenue
drivers

We are in a post-WeWork/Theranos era of founders promising growth without showing any profit. You need to ask yourself "What do we need to show investors?" Users are great, but how is this actually going to make money?

You have to show real numbers and an actionable monetization strategy. This means outlining your marketing and growth strategies — and the mechanisms that will bring in not only revenue but profit.

Revenue strategies can vary greatly, but the following are a few of the most common buckets of digital product monetization mechanisms:

Direct Payment

One-time purchases, subscription models, pay-per-use, or any other mechanisms in which users are paying you directly for access to the product.

Advertising/Marketing Platform

Revenue generated from 3rd parties such as advertisers within the platform, commercial sponsors or partners, or marketing and selling other products.

Commercialization and Licensing

Leveraging your product, or packaged-up data, as a platform to license out to customers for their use. This can be through licensing, white-labeling, or some form of direct payment access.

Ancillary Model

Offering a main service that customers find valuable and then focusing on adding additional features and value at a cost. This can be done through bundling, cross-selling complementary products, a freemium model, or, most commonly, in-app purchases.

There are many ways to monetize a product, and this is by no means an exhaustive list. The right way is the one that will resonate with your audience, so feel free to experiment and be flexible when choosing a strategy.

We’ve been supporting Modular with the release of their new AI platform and product offerings. Early in our engagement, they asked us to design a marketing site to help them grow and segment their sales pipeline. This allowed them better understand, and target, existing and potential users. We took those early learnings to ensure the product landed with their audience and supported their revenue targets.

The product lifecycle doesn’t end with a launch, it goes far beyond. Once you begin to get a better understanding of your customers and their purchase behaviours, it’s vital to adapt, being flexible with pricing, monetization strategies, and identifying unexpected revenue drivers. 

For example, you may see that your primary offering for your SaaS tool is slowly gaining traction, but over and over customers are requesting access to an API for a specific data flow. You may be sitting on a large additional untapped revenue stream and there could be more. Meet your customers where they are!

Trusted
Advisors

It helps to consult the people who’ve been there before. There are a million people on LinkedIn who are trying to sell you a service or product that you may not need. There are critical steps that could cost you if you miss them. There are shortcuts you may not even know exist. Trusted advisors can help you navigate this and more. There is just no substitute for experience.

Find seasoned product leaders, designers, or engineers who have launched products in the past and will be familiar with the nitty-gritty details. They will have the perspective to help you find the forest through the trees. You want people on your side who can make sure you are spending your time, efforts, and money on the right things.

These are the Product Survival Kit items that we recommend to anyone who is creating and launching a product in today's climate. It's a mix of techniques, processes, people, actions and tools that we've seen provide success to many of our clients, colleagues and partners out there. But remember — each product is different, so find the mix that worst best for you. 

It may seem daunting but it is possible to successfully bring your idea or product concept to life today.  This may even be the right moment to go after it. Companies who launch useful and impactful products during economic downturns have a history of surviving and thriving. The next one could be you.

Get the recording of Jona's Collision Talk

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
This guide is based on the collective learnings of the team here at MetaLab but a special shoutout to those who helped us with the writing of this post:
- Angie Amlani, Research Director
- Anshul Sharma, Product Director
- Aaron Geiser, Engineering Director
- Mike Wandelmaier, Head of Design

In case the timing of this post didn’t make it obvious enough, we aren’t big on New Year’s Resolutions around here. But with over 50 projects completed in 2019 and a rapidly growing team, we know better than to breeze forward without reflecting on the lessons that got us here. This is a practice we try to incorporate on a regular basis, and the honesty in our project retros and regular town halls often reveal some of our most valuable opportunities for improvement.

So in lieu of yet another Instagram-worthy highlight reel of 2019’s shiniest wins, here’s a quick rundown of our messier moments from last year (and the advice we wish we’d had back then).

One of our Design Directors on why design doesn’t always age well

metablog

The TL;DR

It wasn’t until halfway through wireframing on a recent project when I realized that I’d neglected to consider what is arguably one of the most important variables in the design of any product: the element of time.

My team and I were on a brainstorming call, and I asked, “What would this look like with completely different content?” From there, the can of worms was open and we saw how unsuccessfully our current execution would withstand the test of time. Our wireframes were designed around very specific—and very minimal—content, but the experience would become extremely jarring if more content was added and changed over time. And it wasn’t just a content problem. There was something inherently problematic about assessing our designs in a state-by-state context since so much of the user experience happened in the transitions that connect those dots.

We’d overlooked the fact that the connective tissue—the transitions, the loading or offline states, the interacted states—reveal a lot about how to accommodate a user’s needs as they move through time. It might sound obvious, but it’s easy to forget that designing for the here and now shouldn’t preclude you from leaving flexibility for future adaptations.

My advice?

No matter how intuitive your layout or how pleasing your color palette, your design won’t be of much use to anyone if it isn’t flexible enough to accommodate a handful of other realities in addition to the one you’re currently facing. You don’t need any super fancy techniques or methodologies to address this, either.

Start by asking if your product’s value proposition changes with different contexts and over time. What can you deduce from previous requirements that might help you predict what will be needed in the future? Look at ideas you’ve previously abandoned and try to argue them back into play.

Lastly, give new prototyping tools a shot; the more fluidity and interactivity they offer, the less dependent we become on states to design for the experience continuum.

Our Director of People Ops on why representation matters

metablog

The TL;DR

The thriving culture and smiling faces you see on our website aren’t just for show. We try to involve our employees in important decisions, encourage dialogue, and put people first. Generally speaking, we have a genuinely happy group of people roaming the proverbial halls of MetaLab as a result. But for a company that prides itself on its remote culture and global perspective, our lack of diversity is a problem.

Everyone deserves to be represented in the spaces in which they live and work.

It's a problem not just at MetaLab, but in our industry as a whole. First and foremost, it's a people issue: everyone deserves to be represented in the spaces in which they live and work. Secondly, it's a business issue: when underrepresentation goes unchecked, the quality of the work suffers. We can’t responsibly build products that serve billions of people from all walks of life if our teams aren’t just as diverse. To do our jobs as people and product designers, we have to actively invest in a community of equal representation, access, and inclusion within MetaLab and beyond.

My team and I spent 2019 trying to be part of the solution, starting with a focus on hiring. We hosted events and attended workshops and training sessions. We removed candidate identifiers from our screening process to reduce unconscious bias and launched a new Careers page to reflect a company where anyone could feel like they belong.

Over the course of last year, our good intentions progressed into baby steps forward. It's something, but we’ve got more progress to make. If we've learned anything, it's that taking a top-down approach will move things farther, faster. So this year, we're working with professionals to integrate diversity, equity, and inclusion into all aspects of our company for a more meaningful impact.

My advice?

Look in the mirror and be honest and clear about where you are and where you want to go. Ask for help, and ensure that it’s a priority at an executive and management level. Then, take small, consistent steps towards implementing change. Hold yourself accountable along the way, but don’t shortchange yourself on the self-compassion you’ll need to overcome the reality of how far you have to go. Most importantly, ensure that these efforts are a transparent collaboration all the way through and give every person at your organization a supportive seat at the table.

Our VP of Partnerships on the value of turning down clients

Photo of Luke Des Cotes, MetaLab's VP of Partnerships

The TL;DR

The folks in the tools are what make our business what it is. At the end of the day, our model is pretty simple: we hire the best people in the world to do incredible work with great clients. Rinse and repeat. Our employees could work just about anywhere in the world, but they choose to work at MetaLab.

That means it's my team’s job to make sure MetaLab is a compelling place to be through the projects we bring in the door. Easy to preach, sure. It’s a whole lot harder when that means leaving millions of dollars and interesting work on the table because something about a client just doesn’t feel right.

We’re relationships people, so we feed off of energy, good or bad. When it’s good, it’s really cool to see the positive impact that it has on the work. When it’s bad, we take it seriously and do something about it. We’ve had enough very good and very bad client relationships to know that when the team suffers, the products suffer, and nobody walks away getting what they came for.

This past year alone, we ended up saying “No, thanks” to hundreds of projects in the name of protecting our team. The ones that keep me up at night are the few that slipped through the cracks, like the two clients that we had to part ways with and the handful of others we should have ended things with much sooner. A bad apple spoils the whole barrel and when our team feels tired, uninspired and frustrated as a result, that’s (partially) on me.

My advice

Take your time and then trust your gut, even (and sometimes especially) when clients are in a rush to get things signed off. Don't hesitate to slow things down, book that extra call or ask to meet in person before agreeing on contracts. The same goes for stress testing anything that doesn't feel right throughout the process—make a point of challenging them and seeing what happens. Regardless of how big the name or how deep the budget, these relationships are two-way streets. Like any good relationship, they take time and work to cultivate, and the early interactions are typically windows into what to expect down the road.

One of our Engineering Directors on why it’s good to get it wrong

metablog

The TL;DR

We have a very high bar for shipping functional, polished products, so the better we can integrate our design and engineering teams, the better the quality of the end result. Where many traditional teams usually take a waterfall approach to their development phases, I spent 2019 experimenting with different methodologies to see if I could set the quality bar even higher, faster.

On estimation calls, I’d push to get development started on projects as early as possible. This would allow the team to start looking under rocks, asking questions, and laying a foundation for the rest of the product architecture. In some cases, this worked really well and made projects a million times better. Other times, it was obvious that we’d pushed it too far.

How could development be expected to build a product that hadn’t been designed yet? How could designers be expected to map out the data flow when they didn’t yet have the actual data? Both questions were equally valid and frustrating, so we had to get creative with staffing projects to keep things moving forward. Still, what we’ve gotten from these experiments far outweighs the perceived safety of a singular approach to engineering. As the classic “waterfall vs. agile” debate rages on, we’re focused on building an engineering team and schedule that maps to each project’s unique needs.

My advice?

Don't be afraid to tinker with the status quo. You might break some things in the process, but you’ll learn a lot more in veering “off-course” than you might have otherwise and your solutions will be even more foolproof as a result. But before you start taking things apart or moving in an unconventional direction, make sure you’re clear about your team’s non-negotiables.

I managed to feverishly champion finding ways to be 10% better while also reiterating the need for everything to be delivered on time and on budget. Whenever you run a new experiment, over-communication (both internally and with stakeholders) is the key to protecting the integrity of the product during the trial and error that comes along with trying something new.

Our COO on why imposter syndrome is worth talking about

metablog

The TL;DR

“What do you do at MetaLab?” The question wasn’t out of line or invasive for a networking event, but it didn’t make answering it any easier. Like I had done so many times before, I found myself sharing that I “worked in Operations” rather than telling people I was the COO of MetaLab. I’m immensely proud of where I work and the teams I get to lead, but sometimes I'm still uncomfortable with the title that comes with it. In my mind, broadcasting my C-level role sets me up to fall short of expectations that people might have of what a “good COO” should be. Underpromise and overdeliver, right?

It wasn’t until well into my career that I had a name for the healthy dose of self-doubt I’d carried with me over the years: imposter syndrome. I can tell you from experience that this negative self-talk doesn’t discriminate across skill level, expertise, or any other differentiator. While it’s a mild nuisance for some, it can be debilitating for others. For me, the voice telling me that I could do better makes it hard to celebrate my successes, but it’s also what motivates me to succeed in the first place. As a result, I’ve tried to embrace the ways in which this voice serves me and be more aware of what happens when it starts to get in the way.

My advice?

There are no dumb questions; your curiosity is an investment in your growth.

I find that past performance is a great indicator of the future, so the quickest way to stop thinking you’re falling short is by internalizing any cold, hard evidence to the contrary. If others tell you you’re doing a great job, you probably are (and probably will again). When you need direction, keep in mind that there are no dumb questions; your curiosity is an investment in your growth. For example, I recently joined a project team for a couple of months to gain first-hand product design knowledge to boost my subject-matter confidence (spoiler alert: it worked). Also, stop trying to “fake it ‘til you make it:” I’ve learned that humility and a willingness to learn gets you a lot further.

New and improving

It’s good to talk about these things. And talk and talk. But instead of just waxing poetic about all the things we’ve learned, we’ll be a lot more comfortable when we have tangible changes to point to the next time we sit down to chat. We’re approaching this just like we would any other project: take things week by week, step closer, step back, invite feedback, implement learnings as early and as often as possible, and always, always produce something real in the end.

Wish we’d addressed a different topic, or want us to dig deeper into something that we covered here? That’s what our AMA forum (answersplz@metalab.co) is for. We’re all ears.

Celebrate little wins
Embrace the scroll
Coach them though big ideas
Embrace the scroll
...make sure anyone can use it
Give them one task at a time
Teach by example
Create a 'consumer-friendly' feel
Focus on the most common user needs, but...
Start with mobile
Principles we
can use today
Share:
Twitterfacebookemail