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.
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 moreTeams, 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 moreToo 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 moreThe 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.
A coaching partner who will help team members grow and thrive
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.
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.
There is no single path to success in new product development, but it can feel like there is only
one way (whether at a startup or a big company) — that of the founders or executives. For these
teams, it can feel like a tightrope walk where any departure from leadership’s vision will lead to
failure. Despite a desire to “fail fast, fail often,” most teams do not actually succeed in that
aspiration, investing millions and wasting months or years. I’ve experienced both the traditional
exec-led product development model and a team-led one. Each of these models has merits, but neither
can guarantee product-market fit. I favor the team-led model because of the positive impact that it
can have in uniting a team, encouraging them to stretch beyond their comfort zone and do their best
work — where both company and personal growth goals align. There are some challenges to work through
in either of these models.
Pressure
In the exec-led model of new product development, there is immense pressure on the founders or
executives to convince team members of the validity of their vision. If a PM lead exists on the
team, their job is to make the product that leadership has envisioned successful — the solution has
been decided. This exerts enormous pressure on team members to buy in, despite misgivings, and
to commit wholly to building out that vision. I’ve experienced both sides of this model. As a team
member, I’ve participated in prolonged debates with leadership who seemed unmoved by the concerns
raised by the team. Unable to change leadership’s mind and exhausted from frequent
debates, the team reluctantly falls in line and builds out the vision despite lingering doubts.
Having acted as the product lead in startup and big company environments, I’ve felt the tremendous
weight of trying to steer the team toward success — there was
never much room for failure. Perceived stumbles resulted in decreased faith from jittery executives
in other parts of the company who sought resources for their own teams. Failure meant the project's
cancellation at a big company. At a startup, a shortened runway and the looming
dissolution of the company.
There is a tremendous expectation to reach certainty as soon as possible and heavy discomfort with
the inherent ambiguity of early-stage product development. This unspoken need from the team and
external stakeholders (e.g. executives, board members, investors, founders) converge on the acting
product lead, making it unwise for them to acknowledge doubt, even though it might be appropriate,
leading to dissatisfaction for all involved. There is immense stress on everyone when the
expectation is to succeed even though that’s typically not the outcome given how often
new ventures fail.
I've also practiced a more iterative, team-led approach to new product development modeled after the design thinking process, as taught by
the Stanford d.school
and practiced by IDEO. In this user-centered, experiment-driven model, team members share ownership
and the responsibility of finding product-market fit. There are discussions, but instead of lengthy
debates, continuous user feedback on iterated prototypes settles many disagreements. This
lightweight process allows team members to take comfort in the structure of how to go about
discovering user needs and potential solutions. Failure doesn't have as much of an emotional punch
because it is part of the learning process. The uncertainty decreases as the team iterates based on
frequent user feedback. In one of my experiences, the prototype that showed the most promise did not
come from leadership. Instead, two team members created it, riffing on each other's ideas. We still
felt pressure to succeed, but it was a weight that we all shared. There was joint problem-solving
and a shared sense of adventure — it was even fun. We were a team trying to figure out a way forward
together rather than just a group of colleagues doing their jobs.
Time and money
In the traditional exec-led model, creating an MVP can take nine months to 1.5 years or more before
leadership decides to continue investing or end the project. Without a clear positive result, the
project will likely languish as the team works on other priorities. The company will have spent
millions on unclear returns.
For example, a startup with eight members may spend a year building an MVP. The company
conservatively spends ~$1.4M (assuming an average salary of $175k) on headcount alone. Similar teams
at a big company would take even longer. All this means is higher sunk costs. If the effort is
successful, then all is well, but it often is not. What the team learns in the process is lost when
they are reassigned to other projects. What is certain is only that they failed.
In contrast, the team-led model encourages quicker experiments and iterations based on user
feedback, so in 12 weeks, the team should be able to validate several hypotheses, discover where
they might have been wrong, and adjust course. The team can build on their past findings — failures
aren't bad because they're just learnings. If there isn’t a way forward — as in one of my
experiences — then the call to stop happens earlier. The cost of these learnings in both time and
money is significantly less than in the traditional product development model. If this approach has
a potentially higher ROI, why do most teams follow the exec-led model?
Certainty, security, and clarity
Being a part of a team with a leader with a clear vision brings a sense of security. This top-down
approach is reassuring because the product leaders know what they’re doing (at least, they project
that confidence). Team members only need to worry about execution. Product managers take on more
project management responsibilities rather than needing to figure out product-market fit. This
command-control approach works well when there are strong signals for product-market fit. However,
the certainty and security might be short-lived if that is not true.
In the best-case scenario, the solution dictated by leadership finds product-market fit. The company
grows and is successful for awhile. At some point, continuing with this top-down process may hinder
scalability and innovation because executives become the bottleneck for decision-making. The
business becomes vulnerable to stagnation and competitive threats. User growth and revenue can
flatten or decline (e.g. Instant Pot),
and smaller, faster-executing companies can
overtake market share.
To remain nimble, companies need to innovate. One such way is to train internal teams in new product
development. Leadership can teach team members to make decisions and be okay with failing if it
means learning. Seasoned leaders may find it hard to trust that the team can make good decisions (as
good as they can) and cannot let go. The team may end up in this quasi-autonomous state where they
make decisions but are then second-guessed, never having the autonomy to make mistakes. It is as
much a learning experience for leadership to delegate as for team members to assume ownership and
responsibility.
In the team-led model, team members who are not used to having so much autonomy, even if it is something that they desire, may
become frustrated.
Prior early-stage product development experience or expert guidance helps the team manage
uncertainty and avoid becoming stalled. Those who are product-oriented and want to experience the
impact of their efforts first-hand do their best work under this model.
When does that team-led model work?
There are a few scenarios where this team-led approach to product development shines:
Many people are attracted to joining startups because of the potential for impact and the opportunity to learn things that would not be available to them in a big company. Inviting them to fully participate in the process as thought partners makes the best use of their drive and energy, while the founders are still hands-on. If initial efforts aren't fruitful, the team will learn and will have learned to fail together, making them more effective in subsequent efforts. When the team is successful, the company will have multiple trusted team members capable of driving product development as the company scales.
This inflection point is a good time for the founders to select talented team members who can lead and train them to make decisions that jive with the original vision. Although the founders cannot be as actively involved as they had been in the early stages of the startup, they can still provide significant guidance in steering the team toward a desired goal. The team needs to experience the ups and downs of new product development and have the leeway to make and learn from their mistakes. This way, the founders can gain confidence that the team can make quick decisions and keep mistakes cheap.
There are likely team members in the organization who yearn for the experience of creating new products but who may need more guided opportunities to learn. These team members are well-trained in their craft and just need coaching through the experimentation process. Given that the company has a stable, growing core product, such an investment would be worthwhile to mitigate the risk of stagnation.
New product development can mean creating entirely new products or adding new features to an
existing product. Instead of getting caught up in lengthy and complex MVP phases, companies
(regardless of size and stage) can prioritize short, iterative cycles with clear goals and
hypotheses. Instead of doggedly building out a full-fledged MVP that may not yield desired results,
the team will have three more cycles (assuming the average of a year-long cycle) to attempt to do so
versus one cycle and a much longer runway.
There is no silver bullet to success in product development. Failures are disappointing, but we can alleviate their impact by learning concrete lessons about users and the market. When there is room to fail, there is more room for risk-taking and creativity and better chances for innovation. Startups shy away from having a process for new product development because of the connotation of bureaucracy and slowness, but the de facto exec-led process exists regardless. A lightweight process acknowledges and alleviates the anxiety of uncertainty and ambiguity. By changing the experience, leadership can approach new product development in a structured, user-centered manner that fully utilizes the potential and skills of the entire team, thus inspiring and energizing them in growing the business and their own professional and personal growth.
How does it happen that someone becomes an a-hole at work? It’s hard to believe that anyone would
begin their day gleefully planning how they might destroy someone else’s. Yet a-holes certainly
exist — we’ve all worked with them at some point.
You know who they are.
What made them that way in your eyes? Did they take credit for your work? Have no regard for your
time by scheduling or canceling meetings at the last minute, expecting you to drop everything? Did
they throw you under the bus or engage in blaming when things didn’t go well? Spread lies about you
behind your back? The a-holes that I’ve worked with wielded their power like a cudgel and expected
me to fall in line.
Whatever their transgression was, I bet you remember how they made you feel. I felt dismissed and
disrespected. Whatever enthusiasm or motivation I had was sledgehammered until I dreaded work. A
short 10-minute drive to the office became a slog toward Mt. Doom. Easy things became hard. Hard
things made me weigh how much my sanity was worth. Sleep became a casualty. My sense of well-being
nosedived, making it difficult to enjoy much of anything, even outside of work.
Despite their harmful behavior, a-holes are tolerated or, worse, celebrated or promoted. No one
calls them out. Sometimes, they’re our bosses or someone higher up in the management chain — they
only behave like a-holes to peers or those lower on the totem pole — which makes accountability for
their behavior even more unlikely. They create unsafe environments where we are on guard, forcing us
to adopt a CYA (cover-your-ass) attitude. Work is miserable because of the toxic environment that
they create. We intuitively recognize toxic culture when we dread coming to work. Our mental health
erodes the longer that we are there. Toxic behaviors, as defined in “Why Every Leader Needs to Worry
About Toxic Culture,” are disrespectful, noninclusive, unethical, cutthroat, and/or abusive. Yet how
can work be toxic if it’s not something any of us want to create?
Most of us aspire to be rational, logical, and data-driven (especially in tech). We tend to seek
numbers and hard evidence and disregard intangible things like feelings. We control our emotions —
often by denying that we have them — and are proud that we can hide them.
Can we though?
Whether or not we admit to them, we have feelings. Those seemingly controlled emotions leak despite
our best efforts. Others are often aware of our emotional state, even if we are stone-faced. They
may not be able to pinpoint the reasons for our feelings but will sense it. Think about the last
time you realized something was “off” with a colleague despite their not having said anything
specific. Our repressed emotions run amok and cause us to act in ways antithetical to creating the
safe spaces we desire. They can cause us to become unwitting a-holes. While it is easy to recognize
and eschew unethical and abusive behaviors such as screaming at a colleague or intentionally harming
others, more insidious are disrespectful or noninclusive behaviors that erode trust.
Some examples of behaviors that have unintentionally negative impacts:
The list goes on as we can all add our experiences to this. These behaviors likely seemed reasonable
to the people who committed them. On the receiving end, we call them a-hole behavior.
What impact does suppressing our feelings have?
The leader who required silence may have meant well and might have been trying to help improve team
productivity by creating an environment conducive to concentration. They may have had any number of
feelings that led to acting the way they did, but those were not communicated. By jumping to
implement a solution without speaking to those who would be impacted, they tried to solve a
non-existent problem, creating confusion, stress, and resentment. Their actual feelings and
intentions remain unknown, but the impact of those unspoken feelings was felt. Sometimes their
impact is so painful that we are unable to even wonder about intent and instead brand those who have
hurt us as a-holes — I have.
In more instances than I’d like to admit, whenever I’ve tried to repress my frustration or anger
about a perceived a-hole, I’ve acted in ways that likely prolonged the conflict, sometimes
exacerbated it. In the face of perceived authoritarian behavior, I’ve reacted with passive
aggressiveness or open defiance. I felt wronged and excused my ensuing behavior as that of an
unjustly injured party, even though that behavior likely caused injury to others. Situations like
these create a chicken-and-egg cycle. Sometimes, the transgression might be minor, but when left
unaddressed, small things compound. The only possible outcome then is for one of us to quit when our
misery becomes intolerable.
So AITA at work?
Labeling ourselves or others can provide temporary relief, but reduces everyone to caricatures.
Vindication is short-lived and we are eventually left with lingering resentment. It might be
comforting to rest in self-righteous indignation, but in doing so, we risk not exercising our
curiosity and avoiding attempts to connect. Resolving conflict is hard and consuming, but ultimately
rewarding work that builds trust.
One of my most transformative experiences was experiencing Stanford’s Interpersonal Dynamics
while in school. It gave me the knowledge needed to address interpersonal conflict. Still, it took me
years to effectively apply the lessons learned at work. Execution is hard in environments that may
not feel safe but can be done with selective risk-taking and practice. Learning to speak frankly
about my feelings and attempting to understand the underlying problem has opened me to different
perspectives, helping me to engage in collaborative problem-solving. In doing so, I have moved from
barely surviving at work to thriving and finding joy in what I do.
By not acknowledging and addressing our feelings, we act in ways that might be unfathomable to
others and trigger similar behavior from them. Learning how to hold constructive conversations, even
when it feels unsafe or impossible because of power differences, will help us to achieve outcomes
that may have seemed out of reach. Aside from not being miserable, our success as leaders (we all
are, regardless of title) depends on recognizing our feelings and appropriately expressing them
(Bradford & Robin, 2021). Learning how to effectively communicate and resolve interpersonal
conflicts improves our mental health, builds stronger work relationships, and helps us to grow
personally and professionally.
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 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. User research can be daunting, but is essential for finding product-market fit.
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. 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, leading to more effective collaboration.