Develop your team’s ability to go from 0-1.
My expertise is in user experience design, with focus on new product development. I have been called the “tip of the spear” because I thrive in ambiguous environments and bring clarity and direction in the search for product-market fit.
Having spent 15+ years in startups and big companies as well as exploring entrepreneurship, I am well-versed in building things from scratch in extremely nebulous and fast-paced environments, whether my title is Director of Emerging Products or VP Design. I know how to adapt and be nimble in highly structured organizations. My intimate familiarity with risk and failure enables me to manage them well — I do not suffer from decision paralysis.
My prior experience as a software engineer, product manager, and product designer fuels my conviction in the importance of the equal partnership of Engineering, Product, and Design (EPD) as the cornerstone of product development, especially when going from 0-1.
Given the inherent difficulty of new ventures, I’ve found that effective team communication is crucial to its success — I’ve taught teams interpersonal communication gleaned from my reflected experiences, applying the lessons from Interpersonal Dynamics at Stanford. My efforts have fostered open communication and the giving and receiving of feedback to create a culture of trust and safety.
In addition to building products from the ground up, I love figuring out what brings people joy at work and how to help them thrive, creating environments that encourage learning and growth.
In short, I help people thrive and grow by deeply understanding their strengths and aspirations.
I spend a lot of time growing this little one too.
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
Many companies follow a traditional top-down product development process, where decision-making is centralized in the hands of executives. However, this approach can hinder scalability and innovation. By empowering team members to make product decisions and contribute to strategic thinking, companies can create new features and products that meet user needs and remain nimble.Learn more
Teams, especially those involved in new product development face immense pressure and tight deadlines to deliver successful business outcomes. To achieve these results, leadership teams must foster a high-performance culture that prioritizes psychological safety. By training team members to effectively resolve disagreements, companies can save valuable time and money.Learn more
Too often, Design is a service org and designers end up pushing pixels despite the fact that Design is most impactful to the business as a full partner in the product development process. To change this, leadership can create a culture where Design has a seat at the table to fully realize their value to the business.Learn more
The most effective partnerships are those tailored to the needs of the team — let’s chat about what that might look like and design the experience together.
People and relationships are the core of my work. When team members thrive, overall performance improves, resulting in more value for end users and better outcomes for the organization.
Open communication is essential in all successful work relationships. If teams are able to raise and discuss issues then they can find a way to overcome challenges.
I'm always curious about the "why" of things, which leads me to ask lots of questions and really understand. This helps me to empathize with others and build effective partnerships that are truly fulfilling.
I thrive in nebulous environments and love to explore, push boundaries and challenge what is possible, despite the discomfort. I seek to learn and continually grow.
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
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
I had the pleasure of collaborating with Tina during a critical phase in our team's design evolution. Tina played a pivotal role in enhancing our design maturity, bringing a clear vision of what makes a successful design team. What stood out to me was Tina's emphasis on individual growth. She was keen on understanding each team member's unique qualities, ensuring that the team had a personalized career path aligned with their aspirations and company’s product goals. Her design leadership had a lasting impact on our team, shaping us for continued success.
I took the interpersonal communications workshop led by Tina. I learned important lessons around how to effectively communicate in difficult situations and how to manage my own feelings in such situations to be able to ultimately move forward. This is by no means an easy thing to do and Tina knew this; this is why she would gently probe us to practice on the spot with other individuals to solidify such a skillset. Tina taught the workshop in true Tina style - ensuring everyone felt comfortable while simultaneously pushing us out of our comfort zone. Her authentic approach and general desire to make sure everyone came out of the workshop with something was evident and appreciated throughout. To this day, when I get upset (whether at home or at work) I take a breath, think about the template of how to communicate in such situations and go from there. It’s been a real game changer!
Senior Product Manager
I thoroughly enjoyed the interpersonal communications workshop led by Tina Nguyen. The discussion included a framework for approaching tough conversations, and I truly appreciated the thoughtful approach Tina maintained throughout the entire program. Each time I participated in the workshop (yes, I attended more than once!), I felt that Tina created a safe space for everyone to share and learn together. I walked away from Tina’s workshop with an enhanced communications skillset, all thanks to her wonderful guidance.
Director of Engineering
Tina played a pivotal role in my professional and personal development. She genuinely cared for each team member’s growth, and she ensured that the projects I was involved in aligned with my aspirations as a Product Designer. Tina has a remarkable ability to create an environment where everyone feels comfortable opening up for candid and meaningful conversations. A particularly memorable experience was participating in an interpersonal communications workshop — it provided a structured framework for navigating challenging conversations in a professional setting. The practice sessions in small groups were particularly helpful, because they allowed us to engage in honest communication outside our regular work settings, which helped create a safe and trusting environment within the team. Tina's leadership in this workshop reinforced her commitment to fostering effective communication and building strong interpersonal relationships within our team.
Senior Product Designer
Working with Tina was a transformative experience, particularly in terms of personal and professional growth. Through her mentorship and guidance, I gained a deeper understanding of startups and honed my abilities to deliver impactful insights. Tina’s dedication to fostering a culture of growth is truly inspiring. Her interpersonal communication workshop encouraged collaborative spirit that propelled projects forward, ensuring synergy and efficiency across teams. Tina’s dynamic approach, from shaping product design to fostering seamless interpersonal communication and expediting development, makes her an indelible mark to any company’s growth.
Senior User Experience Researcher
Tina's interpersonal communications workshop was invaluable for our team. She guided us through a variety of challenging topics like conflict resolution and the art of providing constructive feedback. Her thoughtful approach and wealth of experience helped everyone on the team grow.
Staff Software Engineer
Tina unlocked something in me. In a few short months, I’ve grown more as a designer than I ever had in my career! Tina’s mentoring approach is to steer you in directions that may not be comfortable, but ultimately manifest in that "aha moment" with a stronger solution. But the most valuable lesson was the communication framework she left me with, I became a more effective communicator and I’ve also noticed a culture shift within the team that made giving and receiving feedback a natural and liberating experience.
Tina’s history as an engineer and a designer at start-ups have shaped her into a powerhouse with lots of insights to share. In addition to her research and design skillset, she has an uncanny ability to quickly assess team dynamics and identify and leverage the strengths of each team member. This ensures that ideas flow seamlessly within teams and contributes to the overall success of the project.
Tina's guidance on tackling challenging conversations, providing constructive feedback, and handling disagreements was especially noteworthy. Her advice was practical and directly applicable, which we could immediately put into practice through live pairing and scenario role-playing. Thanks to this workshop, I now have a better framework for approaching interpersonal communications. Beyond the workshop, I was part of an experimentation stream under Tina's mentorship. She played a pivotal role in helping us discover our strengths, voice our concerns, and navigate our way to delivering results. Her approach of asking critical questions, both qualitative and quantitative, along with revisiting her insights and notes from previous experiment streams, significantly improved our team dynamics and flow. Working with Tina was not only professionally rewarding but also a great deal of fun. She is an outstanding manager and a cooperative team player, whose contributions have left a lasting impression on me and my colleagues.
Staff Software Engineer
I had the pleasure of working with Tina and was consistently impressed by her project management, design leadership, and user-centric mindset. As a product design leader with a deep knowledge of best practices, Tina's expertise and dedication were invaluable to the team.
Senior UI/UX Designer
As a leader in a later stage startup or established organization in tech, you aim to innovate and expand the business beyond its core offerings. To achieve this, you recognize the need to delegate decisions to your team and avoid being a bottleneck. However, this can be challenging if your team is not accustomed to navigating the ambiguity of new product development and is used to working with a clear roadmap.
Instead of relying on external firms, your goal is to develop the capability for creating new product offerings in-house. You believe that your team is your competitive advantage and want to invest in their growth and talent. To enable your team members to take ownership and execute independently, they need to be empowered to fail quickly and learn from their mistakes. This can be achieved through coaching. Once your team becomes proficient in the new product development process, achieving product-market fit in a fast and cost-effective manner will not be unlikely.
As a startup founder and CEO, and public company exec, Tina was one of my most trusted advisors. Good managers solve hard problems. Tina goes one step further. She builds trust and digs into the personal whys (she is one of the most authentic people I've met) but is also pragmatic – she prioritizes the company first, followed by the team, then the individual. This gave us a deeper understanding of our business and helped us make better decisions.
You'll receive a document with more details on partnership possibilities.
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.