Cofounder problems: one list for two founders to fix together

A founding team can come apart over a pile of small things nobody wrote down, not one big fight. This guide covers cofounder problems and one list for two founders to see, discuss, and fix together, so the small things stay small. You will get a list of the issues worth tracking, a way to phrase them without blame, and a weekly habit that turns entries into decisions.

Why cofounder problems hide until they explode

Early on, you and your cofounder are busy. You ship, you sell, you raise. Friction feels like a distraction, so you swallow it. "They always push the demo date" becomes a private note in your head. Your cofounder has their own private notes about you.

Three months later, one of those notes comes out in a tense meeting. It comes out with interest. Now it is not about the demo date. It is about respect, effort, and whether this is working at all.

The problem was never the demo date. The problem was that it lived in one person's head with no record, no attempted fix, and no outcome. Writing it down early can take some of the heat out. A line on a shared list is easier to talk about than a grudge.

The common cofounder problems worth writing down

You do not need to log every annoyance. Log the things that repeat or that block decisions. Here are common areas to watch:

• Role overlap. Both of you answer the same investor email, or neither does.
• Decision rights. Nobody knows who has the final call on pricing, hiring, or product scope.
• Pace and hours. One of you works weekends and quietly resents that the other does not.
• Money. Salaries, spending limits, and how long the runway really is.
• Equity and vesting. What was promised, what is written, and what happens if someone leaves.
• Hiring. Who to hire first, and who manages them.
• Communication. Updates that come too late, or decisions made in a side chat.

If a topic has come up twice, it belongs on the list.

One list for two founders, not two lists

When each founder keeps their own notes, you get two stories. Each story makes its author look reasonable. Then you argue about whose version is true instead of fixing anything.

One shared list changes the conversation. You both see the same problem, the same attempts, and the same results. Nobody has to remember what was tried in March, because it is written next to the problem.

Problem Graph is a personal problem and solution journal drawn as a map. You write a problem in one line, attach the solutions you try, and record whether each one worked, partly worked, or failed. You can link problems that belong together. Everything is private by default, so only you see it until you choose to share.

For two founders, the useful piece is the private network. You create a network, give your cofounder the invite code, and share a problem into it. Members of the network see it. Nobody else does. Keep in mind that the app says anyone with the invite code can join, so treat that code like a password and send it only to your cofounder.

Sharing works through a main node. You mark one problem as a main node, and only a main node can be shared. When you share it, its solutions, their outcomes, and the requirements they need go along with it. A problem you only link to it stays in your private graph. That is handy: you can keep a raw, personal note linked to a shared item without exposing the raw version.

The same shared-list idea shows up in other small groups. If you want to see how it plays out elsewhere, read how a hackathon team keeps a shared fix list or how a tenant association runs one shared list.

How to log a cofounder problem without starting a fight

The wording matters more than the tool. A problem written as an accusation will be read as one. Use these rules:

1. Describe the situation, not the person. Write "Investor follow-ups go out late" instead of "Sam never follows up."
2. Keep it to one line. One line is enough in Problem Graph, and it forces you to name the actual issue.
3. Put it in the right lane. The app has four lanes: personal, work, expert, and scientific. Most cofounder issues go in work. A worry about your own burnout might go in personal and stay private.
4. Add your first idea as a solution, not a demand. Solutions start as ideas. You mark the ones you are trying later.

Here is a worked example. You press Enter on this line in the work lane:

We disagree on when to hire the first engineer.

It lands on the graph right away. Then you attach two ideas as solutions:

• "Agree on a runway number that triggers the hire."
• "Each of us writes the role description separately, then compare."

You add a requirement under the first idea: "Up to date runway numbers." Now the map shows that the first fix depends on something else being true. You mark this problem as a main node and share it into your two-person network. Your cofounder sees the problem, both ideas, and the requirement, all phrased as shared work.

The hiring example on the graph, a few weeks on. A made-up founding team, not a real company or result.

Turning entries into owners, decisions, and fixes

A list that only collects complaints is worse than no list. Every entry needs to move toward an outcome.

When you agree to try a solution, mark it as one you are trying. When it has had a fair run, record the result: worked, partly, or failed. In the example above, maybe the separate role descriptions showed you both wanted different people. That solution "worked" because it surfaced the real disagreement. The runway trigger might be "partly" because you agreed on a number but not on what counts as revenue.

Do not delete failed fixes. The home page's own line is worth taking seriously: "The graph is honest. A solution that failed three times stays on the map as a failed solution, and that is exactly what the next person needs to know." For founders, the next person is often you, six months later, about to try the same thing again.

Ownership is a convention you set, not a feature. Put the owner's name in the solution line, like "Ana: draft the runway rule by Friday." It keeps accountability visible on the shared item.

Link related problems. "Hiring timing," "salary levels," and "runway length" are probably one knot. Linking them can show that three arguments are really one money question. As the home page puts it, patterns show up on the map that never show up in a list.

If you get stuck, you can ask for suggestions. The AI proposes new solutions grounded in what worked for others on similar problems. Treat these as prompts for discussion, not answers. You two still decide.

A weekly review ritual that keeps both founders honest

The pages describe sharing, linking and borrowing, not reminders, so the habit has to come from you. Agree which founder keeps the list; the other reads it and raises items. Put 30 minutes on the calendar each week. Same time, same place.

1. Open the app together. Filter by Network to see only what you have shared with each other. Switch to the List view beside the map if you want to go line by line.
2. Update outcomes first. The keeper marks anything you tried last week as worked, partly, or failed. Facts before feelings.
3. Each founder raises at most two new problems. The keeper writes them in. The cap stops one person from unloading a month of frustration in one sitting.
4. Pick one problem to act on this week. Choose the solution to try and write the owner into it.
5. Look at the map once. Check whether new items link to old ones. Repeating clusters are where the real issues are.

Because your problems are saved to your account, they follow you to any phone or computer you log in on. You can review on a laptop in the office or on your phone on a walk. The app runs in the web browser.

Frequently asked questions

What are the most common cofounder problems?

Unclear roles, unclear decision rights, mismatched pace, money and runway, equity and vesting, hiring, and poor communication.

How do you bring up a problem with your cofounder?

Write it as a one-line description of the situation, not a charge against the person, and attach one idea you would like to try. Bring it to a regular review instead of raising it in the middle of a stressful day.

Should cofounders track equity and role disputes on the same list?

Yes, and link them, because role changes and equity can be connected. Keep the list as a record of what you discussed and tried; for anything legal about equity or vesting, talk to a lawyer, since a journal is not legal advice.

When is a cofounder problem a sign to split?

When the same core problem has several failed solutions on the map and neither of you has a new idea you both believe in. A record of honest attempts makes that conversation calmer and fairer, whichever way it goes.

Get started

Start small. Open the app, write the one cofounder problem you have avoided raising, and attach the first thing you would try. If the graph is empty, the "Load example set" button shows how problems, solutions, and requirements fit together. When you are ready, create a private network, send your cofounder the invite code, and share that problem as a main node. You can browse the public network without an account; to add problems, create one with a username and a password.

Try Problem Graph: it is free, and you can look around the public network without an account. Write one problem down in a line and attach the first thing you will try.