Building for private capital: Product principles that power Carta

Building for private capital: Product principles that power Carta

Authors: Nicole Kahn, Webb Allen
|
Read time:  7 minutes
Published date:  June 17, 2025
Our product principles keep us bold, focused, and solving real-world problems. Here's what guides us and how we craft software for the unique world of private capital.

Ever wondered how the tools powering private capital markets actually get built? At Carta, we’re not just coding features—we’re building the tools that help founders, fund managers, and admins turn ideas into reality. For us, building software isn’t just about lines of code. It’s about helping the industry work better.

We do this with a set of product principles that keep us bold, focused, and solving real-world problems. These principles steer everything, from tricky decisions to how we deliver value every day. In this post, you’ll get an inside look at what guides us (how we work) and how we craft software for the unique world of private capital (how we build). 

Whether you’re deep in product management or just curious about how tech teams stay on track, you’re in the right place!

howwework-(1)

How we work

How we work - 1 (2)

Start with why

The first two questions for every project:

  • What is the customer problem?

  • Why should we fix it?

We live in a world of endless problems and a sense of anxiety about solving all of them. For us, the why is more important. Why this problem? Why now?

Our ‘why’ is anchored in customer problems first. We solve customer problems to solve Carta problems. 

Putting it into practice

Every project at Carta begins with a “Starts with Why” brief. This is where we advocate for our customers and clearly articulate the problems they're facing. We get explicit about the customer struggle. We define success and discuss what it would look like to fix the problem set. We make a case for the urgency of now. We start with why. 

How we work - 2 (1)

Solve for the system

We build complex workflows for private capital. 

To do so, we need to deeply understand the inputs, outputs, and players in order to elegantly solve problems. We start by mapping the system. Then, we think through how products and services work together to deliver seamless solutions. 

Our products are more effective when we understand the system and simplify through software.

Putting it into practice

Journey maps serve as our starting point. We map the current state of the user journey, including external users and internal teams. We layer on pain points and opportunities. Once the user journey is mapped, we ask: Should we cut steps and reduce human input? Can we parallelize a serial workflow? Is our old service model still relevant with these technology advances? Now, imagine the future state with software as the lever for transformation. Identify where software should change service. Conversely, identify where software creates a state change in user experience. Solve for the system. 

How we work - 3 (1)

Build for the way the world should be

We're not here to play by the old rules. We're here to rewrite them.

We design every product, process, and decision for the world as it should be, not just as it is. We push past convention with purpose, test boundaries with intent, and stay relentless in pursuit of what's next.

From replacing paper stock certificates to advocating for policy changes in Congress, our goal is always to expand access, transparency, and fairness in private markets. We scrutinize as we simplify the way work gets done.

We don’t believe in building products that simply automate today’s broken workflows or offer “check-the-box” compliance. Instead, we design solutions for where the industry should go.

We commonly question whether the way work gets done today will hold in the future world of software automation. 

For example, we might ask:

  • Should GPs review and approve every single 1099?

  • Why does investor reporting drag on for months?

  • Why do we define accredited investors based on wealth instead of knowledge or experience?

We recognize that there’s an inherent tension between what’s practical today and our bold future-oriented thinking.

Putting it into practice

Let your customers guide you. When they express frustration with manual or repetitive tasks, it’s an opportunity to rethink the experience and take a meaningful leap forward.

Don’t wait for a policy change to ship something today.

Surface and escalate the potential for ‘rule breaking’ paradigm change

How we work - 4 (1)

Data model first

A workflow is only as good as its underlying data model. Without a core understanding of the data needed, its logic and connection points, a workflow is useless. When designing anything, we must start with a data model, then create an intuitive workflow, accounting for the relevant inputs and outputs along the way.

For data models to stand the test of time, they should be flexible as we iterate, allowing for schema evolution.

Putting it into practice

Use the data model to align everyone on the inputs and outputs across a workflow. Use a ‘Jobs to be Done’ (JTBD) framework to design an intuitive user experience for the workflow. Ensure that we’re not shipping our data model and expecting users to figure out what to do on page. Conversely, don’t design a workflow that doesn't factor in the needs of the data model.

How we work - 5 (1)

Complete

For our software to truly help customers, it needs to handle entire processes from start to finish.

In the past, we focused on automating the most time-consuming tasks. We ended up with a series of steps, some handled by people and some by software, but they didn’t add up to a seamless experience.

Our new goal is Complete. 

Each team defines what “complete” means at the start of each project. This doesn’t mean that all use cases must be covered by a software-only experience. That’s for each team to decide. Roadmaps should iteratively meet the definition of complete for a Job to Be Done, before moving to the next high value opportunity. 

Audit each persona’s JTBD to shape the definition. Trade-offs and risks should be considered before dropping a project’s completion target.

Putting it into practice

Which use cases must be covered by software? Which can be covered with service?

How connected does this feature need to be to the rest of the Carta platform to be considered complete? 

Will a better UI/UX create a lasting impact?

howwebuild-(1)

How we build

How we build - 1 (1)

Give a headstart

We’ve helped tens of thousands of companies build cap tables. We have thousands of venture firms and investors that got started at Carta. We are experts at startups and investing. 

When customers use Carta, they start with an advantage. We provide opinionated workflows and smart defaults to help customers make the right decisions quickly so they can focus on growing their business or managing their investments. 

For each workflow, we should ask ourselves, “Have we given our customers a headstart?”

Putting it into practice

As workflows are automated and simplified into products, teams should incorporate industry and Carta best practices. This might take the form of fewer choices, a pre-filled default experience, and a reduction of custom options.

How we build - 2 (1)

Connect the nodes

Many different people use Carta to do many different tasks. Our job is to know who in the ecosystem needs to be informed as each update  occurs.

We’ve built an event-based accounting platform and equity management system to do just that.  As an event is ‘read’ in one part of the platform, it  ‘writes’ to everywhere else it is needed. Events can vary in size, but all are significant. They can be as simple as a new expense recorded to the GL, or as complex as a liquidity event.

Connecting the nodes saves customers time by bringing key experiences together, removing friction from daily workflows, and reducing the need to reach out manually for data updates.

Putting it into practice

For any new feature or workflow that processes an event, understand who in the private capital ecosystem should know about the event. 

Think through the JTBD of the personas in the network. Do they need to be informed or involved in processing the event?

Does data need to show up differently for each node?

Define the ways you will connect the nodes, for today’s use case and tomorrow’s.

How we build - 3 (1)

Never enter data twice (NED2)

Once our ERP knows something, we should never have to ask for it again. After a firm or user enters a piece of data it gets stored as a source of truth in the ERP, making it accessible across the platform for the associated entity. As we build out forms, pages, and features, we eliminate duplicative data entry on behalf of our customers. 

Re-entering the same information feels frustrating, repetitive, and unnecessary. By using the data we already have, we reduce friction and accelerate our users’ time to value. Always draw from what we already know.

As we eliminate duplicative entries, we eliminate errors.

Putting it into practice

Teams should look upstream and downstream of the data model to identify: 1) data sources you can draw from, and 2) data fields you can propagate to

How we build - 4 (1)

Escape hatches, not edge cases

As we build software at Carta, we cover the happy path while not getting stuck on the edge cases.

To be effective, we need to serially build on-ramps and off-ramps into the product experience. Data-in should be just as easy as data-out for our customers. We recognize where a customer's use of Excel is a good enough solution and we provide a means of integrating with it. 

Putting it into practice

For each delivery model (full service to no-service), determine how work should be completed, handed off, and connected to offline tools and work practices.

How we build - 5 (1)

Show our work

A customer’s confidence in our software relies on fundamentally trusting the underlying data. To satisfy our customers, we need to answer the question: “Where did this number come from?”

Showing our work also gives us the opportunity to highlight the core value propositions of our software: complex, networked calculations done seamlessly. 

Where it makes sense, the product experience should be traceable and auditable.

This means:

  • Values can be viewed by their underlying calculation.

  • Changes can be annotated with when, why, and by whom.

  • Extracted data can be sourced back to its origin document.

  • Data validations surface  behind-the-scenes work  and flag relevant blockers.

The Carta platform should be able to answer the questions that give fund operators, auditors, and founders confidence to trust and act.

Putting it into practice

When starting a new project, Carta teams should determine how important it will be to our customers to have the data auditable and traceable in the product. 

Consider these as potential opportunities to show our work:

Places where we want to spotlight high-value data and differentiate the experience

Workflows with multiple collaborators and frequent changes

Core equity/accounting principles that are not well understood

Frequently asked questions, as indicated by our Delivery teams

Topics that would reduce support tickets filed

How we build - 6 (1)

Tools for anybody

We’re building Carta to work for everyone in the private equity ecosystem. 

When every party uses the same experience, the system becomes more scalable, adoptable, and powerful. Rather than bottlenecking workflows through staff-only tools, we are building a shared, self-serve platform that connects the entire network.

We start by exposing the simple, then expand to the more complex over time.

Putting it into practice

When starting a new workflow:

Identify the user personas using the workflow

Envision the experience of each external party completing their end-to-end work without Carta’s involvement

Identify where they can be self-sufficient and where they need Carta staff

Watch for high risk, high complexity, and potential for irreversible errors

Consider AI agents as the responsible party for completing work

Nicole Kahn
Author: Nicole Kahn
Nicole Kahn is the VP of Design at Carta, where she leads a talented team tackling complex problems across equity, finance, and the future of private capital. Before Carta, she scaled the Technology Design Team at WeWork and created meaningful products, services and experiences at IDEO. She also taught design research, creative problem-solving and leadership at the Stanford d.school. She loves deeply human, intricate design problems. She believes no good design is done alone and thinks a beautiful system map makes everything better.
Webb Allen
Author: Webb Allen
Webb Allen leads the cap table product teams at Carta. He works across design, data systems, and platform APIs to deliver impactful user experiences for managing equity at scale. Prior to Carta, Webb managed the machine learning and optimization platforms at Marketing Evolution, and led investment research for the venture funds at Tremendous View and Landscape Capital Management.

DISCLOSURE: This communication is on behalf of eShares, Inc. dba Carta, Inc. ("Carta"). This communication is for informational purposes only, and contains general information only. Carta is not, by means of this communication, rendering accounting, business, financial, investment, legal, tax, or other professional advice or services. This publication is not a substitute for such professional advice or services nor should it be used as a basis for any decision or action that may affect your business or interests. Before making any decision or taking any action that may affect your business or interests, you should consult a qualified professional advisor. This communication is not intended as a recommendation, offer or solicitation for the purchase or sale of any security. Carta does not assume any liability for reliance on the information provided herein. ©2025 Carta. All rights reserved. Reproduction prohibited.