Unlikely’s approach challenges the typical
top-down model by streamlining the product
development process. Instead of getting caught
up in lengthy and complex minimum viable product
(MVP) phases, we would prioritize short, iterative
cycles. This empowers your team to easily adjust to
shifting priorities and swiftly make improvements
based on their insights. By following this rigorous
and systematic approach, we ensure that your initial
investment is not left with unmeasured and potentially
I will provide hands-on coaching to a team of 4-6 (some combination of Engineering, Product and Design). We will focus on:
By the end of the coaching period, the team will have conviction in their current direction based on iterative learning, or a decision to pursue a different line of thought.
Who it’s good for
Small teams at startups or established organizations looking to quickly find product market fit in a new area.
Tina transformed how our team developed new product directions. Previously we had no shortage of ideas, but any given one required a heavy engineering investment, and we didn't have enough conviction in any single one of them to feel confident investing resources. Tina showed us how to move quickly and iteratively from the highly uncertain brainstorm phase to getting working demos in front of users with as little over-engineering as possible. This gave our team the quantitative and qualitative user feedback we needed to have confidence in where to invest our time and resources.
Senior Director of Engineering
Tina helped turn what could have been a very stressful do-or-die situation at a startup into a period that I look back on as simultaneously one of the most effective and the most fun. She was key to helping our team gel and go from idea to multiple UI prototypes, and then public launch within 2 months. Two things stand out that were most helpful to our team: (1) Her incredibly quick but deep user research and synthesis: I have never seen anyone more effectively use user research tools available, and turn qualitative research into something thoughtful and actionable (2) The way she involves the whole team in the entire process: Decision-making was clear and transparent, and involved the team in ways that were helpful but not distracting, and inclusive without being stymied by group decision paralysis.
Engineering Technical Lead
Tina is a powerhouse. She joined us on an in-flight product that hadn't yet found PMF. She quickly took on the vision we were working towards, conducted user research, and developed the user personas and UI prototypes that drove the MVP. Her ability to identify real user needs narrowed the scope and focused everything we were building. She's a delightful collaborator. Tina's high energy, sense of humor, openness, and eagerness to share and train others are all critical assets in the ups and downs of startup life.
CTO and Co-founder
Designers can be difficult to work with if you are unaware of the challenges that make their jobs
impossible. The challenges might be unavoidable, but understanding and acknowledging them may
transform a troubled relationship into an understanding, collaborative one.
(You can use these to prank your favorite designer, but I do not recommend it unless you have a great relationship.)
This common situation — pitfall #1 in my post "Top 10 mistakes startups make in user research (without a designer)" — happens at both early-stage startups and established companies. Sometimes, competing priorities create budget issues. Sometimes, inertia. A designer asks for user research when there is a gap in understanding. Unless they focus purely on visual or graphic design, designers can't do their best work without understanding the user.
Asking designers to rely solely on feedback from leadership or the rest of the team is insufficient and can be misleading. All opinions are valid without user feedback, but the highest-paid opinion carries the most weight. Accepting feedback from leaders who do not have design expertise forces designers to create what they believe to be subpar user experiences, making it difficult to do their best work.
Engineers can spend a lot of time struggling with browser and platform idiosyncrasies to build the high-fidelity mocks that a designer creates. They wrangle with unseen challenges to meet strict deadlines and still take the time to fix awkward interactions that they spot in the designs. Yet when they push the code live for review, their designer creates a laundry list of additional UI fixes. These fixes don’t impact functionality and would take more time than might be available to complete.
When I was a front-end engineer, I corrected design mistakes during implementation when I thought there was a design oversight; I didn't realize that I was wasting time and creating additional work because the designs were purposeful and optimal given the constraints. Later, as a designer, I spent long hours perfecting interactions, struggling with the edge cases, incorporating user and team feedback, and ensuring that UI elements were cohesive, elegant, and intuitive. I thoroughly documented the details to make implementation easy, yet when the UI was built, it looked like someone had thrown up all over it — it was almost the same but, to me, glaringly not.
All the elements were functional, but the proportions, spacing, and many other details did not match the mocks I had toiled over. I was frustrated to have spent all that time and effort to perfect something, only to not have it be built to spec. I was upset until I realized that my training as a designer enabled me to see details invisible to many engineers (including me when I had been an engineer) but are essential to the experience. Designers insist on the details as fervently as engineers insist on tabs versus spaces (or the other way around).
Teams that are not in the habit of soliciting user feedback rely on personal opinions to evaluate designs. While they should always feel comfortable giving feedback on UX, they are not the end users (see pitfall #2 of "Top 10 mistakes startups make in user research (without a designer)"). The team does not realize that their opinions are just that — subjective opinions — so it exerts pressure on the designer to make changes.
Imagine how jarring it might feel if code reviews were a communal activity where many team members in other (possibly non-technical) roles had free reign to give their opinions. Feedback from people without an engineering background would likely be misguided, confusing, or blatantly incorrect. However, designs are more approachable by lay people than code, so designers are subjected to this treatment of their work.
In addition, the ratio of designers to everyone else is skewed, so there might be just one designer explaining design decisions to 10 or more people. Multiply that by the number of UX interactions and UI elements, and the experience quickly becomes overwhelming. Endless debates ensue and are settled by leadership dictating how things should be. The subtext in these conversations is that the designer cannot be trusted to make UX decisions despite their specialized training and expertise.
When the designer listens to but rejects a given team member's suggestion, that person may escalate the suggestion (e.g., to the founders, in a startup or a senior leader). This terrible dynamic sets the precedent for resolving disagreements by pulling rank, leading to a frustrated designer and questionable user experiences. Design decisions based on a single opinion are dangerous, even when the suggester has expertise (some team members claim expertise as justification regardless of whether or not they actually have it). To override design decisions is to strip a designer of agency and undermine them. Design mistakes should be sussed out with user feedback. So when you disagree with a design decision, it’s more productive to advocate for user research or usability testing than to wear down the designer.
No one says this, but that’s effectively the message when they proffer unsolicited feedback from family members. Debating design decisions is hard. It's impossible to do while also trying to avoid accidentally insulting someone’s family. This is especially bad if that person is the CEO or founder. It puts the designer in an impossible position and cripples their ability to respond unless they are highly adept at diplomacy. The seeming disregard for years of training and experience creates friction.
A product manager working under tight timelines, shifting priorities, and an overwhelming workload might feel there is no time to consult with a designer early in planning and instead sketch out some rudimentary wireframes of a pre-conceived experience and ask the designer to quickly convert them into high-fidelity mocks. A designer who has not been on the project will not have enough information about the problem or the target user and is now denied the chance to brainstorm and evaluate alternatives. When working with a user experience designer (aka product designer), this assembly-line setup discounts their skills and asks them to simply push pixels (about as much fun as being a “code monkey”).
Tabs are often a fast and easy shortcut to adding functionality without disturbing the existing design. But they are also the first step to a cluttered UI in a graveyard of features languishing for user attention. Tabs are expedient and can be changed later, but that follow-up work often falls off the to-do list when priorities change. Well-intentioned shortcuts lead to a confusing experience for users, and designers will bear the judgment for bad design. Asking for a tab isn't always bad, but it implies that designing experience doesn't require thoughtfulness and consideration, effectively devaluing the contributions of a designer.
When feature adoption doesn’t live up to target metrics, the team may question whether users know the feature is available. They may suggest visual changes to make the feature more visible rather than reflecting on whether or not the feature provides enough value for the user to use it. The feature may be buried, but no number of onboarding wizards or callouts will entice users if it does not fit their workflow. A designer may advise revisiting the value proposition, but they may be ignored if the team is already convinced of product-market fit. Debates about UI treatments and visual design will have little impact if the team is mistaken about the user needs. Under pressure, the designer yields to team opinion and creates changes that eventually prove fruitless.
It is always heart-warming when a non-designer cares so much about user experiences that they read articles or listen to talks about design and enthusiastically bring them back to the team. They may then excitedly recount a wonderful lesson they learned and translate it into advice for the designer that effectively means: "Create user-friendly experiences.” This is the equivalent of telling an engineer to write high-quality code. The designer will already know core design principles. A non-designer trying to educate them on something fundamental is likely to be interpreted as questioning their expertise.
Designers in startups are often the only ones doing all of the above. They are responsible for interviewing users, designing visuals, drafting copy, creating user flows, developing marketing collateral, and likely more. Each of these responsibilities is a discipline with its own challenges and can quickly lead to burnout if undertaken by a single person. This versatility in a designer might be treated as common and expected, but the designer is rarely compensated for what, in reality, are several roles. Wearing different hats is necessary for anyone at a startup but shouldn't be taken for granted.
Each of these situations is frustrating, but the weight of it all can make a designer’s work unbearable. So when the designer you work with is upset, consider which of the situations above they might be struggling with. Having honest conversations when difficult situations happen can resolve many disagreements, but it is a learned skill to do so effectively. The teams that have learned how to do so through interpersonal communication training have found it to be pragmatic and immediately applicable, leading to more effective collaboration.
The startups that I’ve worked with in the past have made common mistakes with user research. These mistakes were avoidable because they were known to designers, but these startups didn’t have in-house design expertise. I’ve also been at big companies with established design teams that made the same mistakes because Design was not a mature practice and was treated like a service org.
At early-stage startups, founders are often the only people to speak to potential users — most startups do not have the expertise or budget (it isn't a priority) to hire a researcher or a designer trained in research. Circumstances set precedents. What was regrettable becomes the norm. When startups do grow and gain the ability to do in-house research, the reluctance remains because the founders believe they already understand the target user. Their success (as evidenced by investments in their startup) buoys their confidence despite the lack of rigorous research.
While the early team could share the responsibility for user research, talking to people is hard. Early-stage startup teams are often comprised of engineers. As an engineer, I never spoke to any users. It took a lot of practice before I could approach people to ask questions. Talking to users can be a struggle for anyone not trained in the process, even executives whose job is communication. User research is a learned skill. The team might be tempted to skip research out of discomfort or in the spirit of moving fast, but that may contribute to the startup's failure.
On the surface, a team may believe in the importance of understanding the target user and their needs but then err in thinking that more user research is unnecessary because they are the target users and can speak on their behalf. However, by working on the product, they already know too much to be representative. This can be tough to change if no one at the startup has enough experience or credibility to disagree with the people thinking about this problem the longest (especially the founders).
Well-intentioned teams that believe in listening to users can make the mistake of creating a list of features and then sending users a survey asking which ones they want. I have seen this multiple times. In most cases, the surveys are biased and can lead the company to draw faulty assumptions. Crafting unbiased questions is difficult if the team has not been trained. Surveys can be helpful if the team has performed qualitative research and uses them to falsify hypotheses. Otherwise, creating roadmaps based on survey results can potentially waste time and money.
Startup teams are naturally excited about their ideas, so when they speak to users, they tend to sell instead. Their questions are variations of: “Would you use this?” In the face of such enthusiasm, people may say something positive to not disappoint. However, this derails the conversation and turns an opportunity to discover unmet needs into another data point for confirmation bias.
Startups should be wary of talking to too few users and mistakenly applying best practices for usability testing to user research. Most common usability issues can be discovered by talking to 5 users. But that only applies to usability testing of a feature or prototype, not to exploratory user research. Usability testing determines if a user can complete a task, whereas exploratory user research is for discovering unmet needs. If the team is still looking for product-market fit and trying to understand potential users, talking to 15-20 people would be more helpful in uncovering motivations and patterns in their behavior.
When teams invest in exploratory research, there can be pressure to get it right, especially if research is done infrequently. This mindset leads to disagreements. The research is unlikely to answer all questions, leading some team members to doubt its usefulness and validity. The purpose is to learn about user motivations and behaviors — complete agreement on the findings isn't the end goal. Research is often not comprehensive, as that would take a long time, so some gaps in understanding are to be expected. Ongoing user research reduces the pressure, ensures that the team has a shared understanding of the user, and helps them to iterate and test hypotheses, increasing the chances of creating something valuable.
Teams can make the mistake of assuming that a product is suitable for everyone. Anyone could use it, but not everyone will. The hope might be that the product will have a large user base. But, at the beginning, the team needs to be specific. Explicitly focusing on a user segment helps the team have a shared understanding of why they build and for whom. When the team allows the target user to remain loosely defined, team members may make assumptions, leading to disagreements about product direction and potentially building a mediocre product that no one wants.
Teams that make changes based on what users say without understanding their reasons run the risk of undesirable outcomes. Building without understanding the underlying needs and motivations may miss the mark and create something users do not value. Users typically cannot articulate what they need (they may not know), so relying on their words for product direction can lead to disappointing results.
Some teams understand that users cannot articulate what they need but mistakenly use that rationale to avoid seeking user feedback (citing Steve Jobs as inspiration for their approach). They build without validating their hypothesis and do not iterate because there is no user feedback. Months to years can pass before the product is available to end users. If the team is wrong about their initial hypothesis, they will have wasted significant time and money. Frequent evaluative user research helps teams to course-correct early and often. Users may not be able to articulate what they want, but they can give feedback on whether or not a prototype fulfills a need.
The founders are the first to talk to potential users, but if they are the only ones, they become the gatekeepers for all decisions. This may work in the early days when the team is small but hard to scale as the team grows. Some are convinced they have the answers, led by their intuition. I believe in intuition and also in the need to validate it with user research to keep confidence from becoming hubris.
The lack of continued user research and reliance on the founders results in slow decision-making. No one person, not even the user researcher, should hold the key to understanding users. Even backend engineering decisions that may not seem like they require any knowledge about the end user can have undesirable ramifications down the road, limiting the experience that the team can build. At that point, it might be too time-consuming and expensive to change. Having a shared understanding allows everyone on the team to independently make decisions that contribute to a better user experience.
User research may feel daunting, but shouldn't be avoided despite the lack of a user researcher or designer. Given the typical startup configuration of engineers and founders, there are ways for interested team members to perform user research. To get a guide for how to do so, subscribe to stay updated with my “Scrappy UX for Startups” series.
New product development is intense and often fails, but it is so much fun — I love it. In my career
at tech startups and big companies, I have worked through many cycles and experienced the enormous
stress and pressure that going from 0-1 has on individuals and how that impacts team dynamics. I
have experienced ambiguity, uncertainty, doubt, and fear in figuring out how to productize ideas,
where failure likely meant the end for a startup (and unemployment) or the dissolution of a business
unit inside an established company. Given that 90% of startups fail, good outcomes are unlikely.
Even so, many people are attracted to new product development while unprepared for its demands — I
was. Many teams excitedly begin believing they have the answer until reality doesn’t match
intuition, despite all their hard work and efforts. At that point, frustrations mount, and tensions
rise, further impeding progress. Having been through this process many times in different roles
(Engineering, Product, and Design), I have multiple perspectives and the experience to lead teams
and coach others through the inevitable ups and downs. It is a bewildering roller coaster ride with
tremendous learning opportunities and impact that is less stressful with experienced guidance.
An essential part of coaching teams in new product development is developing healthy interpersonal
communication among team members. Team dynamics are intangible but critical. The impact of effective
communication may be hard to quantify, but the lack of it can be felt keenly. Team conflict makes
succeeding in new product development even more unlikely.
Some think of “unlikely” as a negative term, as in “but that’s not going to happen.” I think of it
as “yes and.” Even though the reality of creating a successful new product has a low probability of
success, teams can achieve unlikely good things through structured experimentation, short learning
cycles, and rapid iteration. While none of this is revolutionary, knowledge doesn’t necessarily
translate to action. Having a framework for going from 0-1 is helpful and even better when adapted
to suit the team — I’ve done this effectively multiple times by understanding the goals and needs of
the team and its members.
In creating a consulting venture to coach teams on new product development, interpersonal communications, and product design, I aim to share the joy that knowing the positive impact of one’s work brings. Outcomes that may have seemed unlikely before may not be unlikely so.