A full user-centered design process to re-conceive the Mighty product. Redesigned over six months, the platform was gradually rolled out to users throughout the following year.

September 2019–March 2020
My role

Embedded as the only agency resource on the founding team of CTO, CEO, two PMs, I lead all research, strategy, and design. The product concepts, wireframes and some visual design is mine, though final mockups are largely the work of Iñaki Soria and Becky Bochatey.


The golden age of startups

The deluge of unicorn IPOs in the late 2010s introduced a new wave of investors to the world of venture capital. Mighty saw an opportunity and an obligation – to create a tool that could embody the discipline and principles of VC veterans, but in a modern, digital experience.


Redesign the product in 6 months

As an invite-only investment tool, Mighty had a core group of users, but was struggling to find broader traction in the market. EchoUser was engaged to address this low adoption issue head-on; to study, make recommendations, then design the future of the product.

Existing constraints

We were not starting from zero – the Mighty team had a number of ideas as to why adoption was low. Most had to do with existing constraints of the product:

1. The value is not obvious
2. Harder to use than existing tools
3. Unintuitive
4. No way to 'try'


Introducing: Mighty

Mighty helps venture capital offices manage their operations. Honed by industry veterans and designed for the 21st century investor, Mighty offers instructive workflows for managing investments and dealflow, taking the guesswork out of the behind-the-scenes operations required to run a fund.

Investment management for the modern VC

Full lifecycle tracking means Mighty knows – and reminds you – when you’re missing information or files. Industry-standard fund metrics are automatically generated, giving users a crystal clear picture of the Fund’s financing.

Making it easy to play with data

Asking your data anything – search broadly across your organization’s investments, deals, and contacts. Come time for taxes or auditing, simply filter by your most recent activity and export.

Stay on top of your pipeline

From first introduction to cap tables and slide decks, Mighty organizes your dealflow and puts everything onto a single page. The pipeline itself has been designed specifically for weekly deal reviews.

Your new assistant, Queue

Triage your time and energy by forwarding emails into Mighty via Queue. Emails become tasks which can be completed, snoozed, or assigned to others.


A successful product starts with an aligned team

To kick things off, I facilitated a remote Guiding Principles workshop to align the team on the project’s mission and business goals. Themes of collaboration, modernizing workflows, and trust were raised as critical, not only for the product, but our internal team, as well.


Building intuition in a new domain

Developing intuition within a new, technical domain is never easy. Through countless stakeholder interviews, white-boarding sessions, product tear-downs, and mapping exercises, however, I began to understand our user base’s motivations and concerns.

Mapping the ecosystem of stakeholders
Modeling the existing product


Formative & summative research

Though we had a product in use, there were fundamental questions about our users, their motivations and common behaviors. As such, I designed a mixed methods research study with 9 participants, utilizing both formative and summative methodologies

Specifically, we sought to:

1. Identify and evaluate obstacles that prevent user activation.
2. Determine the value that Mighty offers users, in its current state.
3. Determine user needs that the product does not currently address.
4. Identify how different customers use Mighty differently.
5. Establish baseline metrics in satisfaction.



Synthesizing data from the sessions revealed six core findings:

1. Users think in People and Companies
2. There is a goldilocks level of data detail we should strive for
3. Simplify data in
4. Allow for space to play with data
5. Information is currency, put it to work
6. Workflows are the biggest pain


Mapping the backbone of the product

One of the core findings was that users don’t think in terms of discrete investments and deals (the products original organizing principle), but rather, in terms of people and companies.

The challenge then became how to create an information architecture that was intuitively focused on people and companies, but robust enough to continue supporting investments & deals, but as facets of the more intuitive concept of company and people.

Differentiating daily needs from weekly and quarterly ones

Research revealed a dizzying amount of jobs that even the smallest VC offices regularly engage in.

To distill these jobs into manageable design challenges, I first developed personas for the key roles observed across all the VC offices with whome we spoke.

Borrowing from the Jobs To be Done framework, I then mapped the jobs of each persona, loosely evaluating for friction points.

This exercise helped the team realize that the areas where users struggled most were staying on top of their dealflow, managing investments throughout their entire lifecycle, getting data into Mighty, and ad hoc data reporting.

Modeling the full product experience

To address these critical frictions, major feature areas were designed around concepts of Deals, Reports, Companies, and Contacts. These would supplement the existing investment management functionality that Mighty offered.  

A novel idea was also proposed for a feature called Queue that would focus on getting information into Mighty easier.


Creating a high-performance Deals UI 

Deals was the first feature I designed because it’s where our primary user spends the majority of their time.

The challenge with deals was that while each deal is filled with minutae, the desired behavior is frequent looping into/out of deals at a very shallow level.

To support this kind of circular navigation, a tri-panel layout was designed that allowed for easy browsing of multiple hierarchies, progressively disclosing more detailed information.

Finding the Goldilocks level of investment detail

Investments are actually pretty simple: funds are wired and in return, users get equity.

Complexity arises at the aggregate level – tracking the pacing of all investments in a given fund, or pulling together all legal documents for all investments the fund made this year.

The Investments feature was therefore redesigned to support multiple levels of engagement. Users can interact with investments directly on the table, but they can also step back and slice investments by category. Portfolios and  accompanying meta-data are also exposed, supporting even bigger picture thinking.

Simplifying data in

VCs live out of their inbox, and so making it easier to get information into Mighty actually meant that Mighty had to learn to play nice with email.

A concept was proposed that would ingest forwarded emails into the product as tasks. Part data logger, part triage assistant, and part task manager, Queue quickly garnered interest among the Mighty team and would later be one of the first new designs built out.


Enabling a team to make progress towards a vision

As final deliverables for the project, mockups were created for immediate, medium, and long-term development efforts. The clarity of vision that this work brought to the team had the immediate impact of necessitating new staff hires for design and engineering within 2 months of delivery.

As designs were rolled out, new users began using the product and within a year, the user base had doubled.

Further, Queue is the most frequently used feature on the platform.

Annotated mockups


The three questions

Working in such a technical domain taught me how to get up to speed quicker. One trick, in particular, helped a lot: the three question strategy.

The three question strategy can be used whenever there is something I need to learn about, and it has to do with the reality that in such cases, there are actually three questions that need to be asked.

The first is to understand, conceptually, how to frame the question. The second is to understand the language I need to use, the last being the actual question itself.

Learning to trust in trust

6 months simply wasn’t enough time to learn everything I needed to be an expert. As such, trust became a primary focus of the working relationship – trust in the client’s experience and perspective, and trust that the client appreciate’s my concerns, when they are raised. I learned to build that trust through transparent, frequent communications.