Cofounder For Project Planning Software Startup

I have worked with project planning software as a business analyst, then a PM, then a developer, and most recently a PM again. I have used Asana (7 years ago), Pivotal (5 years ago), Jira (3 years ago), and most recently Clubhouse. In my opinion there are a lot of glaring problems with card-based planning

Writing Requirements - I'd like to preface that there shouldn't be an expectation to get every last detail written down but I have gotten so many cards from business owners with one-liners like "We need to send them an email if they sign up", even when we tried enforcing templates. Of course this is the bottom of the barrel type example but I spend way too much time fixing cards. A lot of these business people are very good at what they do and I've seen examples of their work and the level of detail is immaculate. Even when they do follow our templates it's like they've forgotten how to write concisely. I really believe that 90% of card writing should be done by business people and my role as a PM should be to work with developers on solving their problems.

Reading Requirements - there is a reason why literature pertaining to complex tasks has diagrams. For example, OAuth - try explaining that to someone without a diagram. My point is that stuffing sentences/bullet points into a card will never hold the same clarity as a good visual. Anytime I include visuals in my cards I can keep their (developers) attention for much longer. I can't tell you how much time I've spent in planning/estimation meetings where it felt like all of the details were in the card but still so many questions around how it's supposed to work.

Updates To Requirements - one of the most costly mistakes to make is to not update cards after requirements have been added or changed. Duh, right? Well this seems to happen a lot, ranging from small details to much bigger changes. This happens when we discuss stuff on slack but the new information is not added to the card. Next thing you know, QA has spent an entire day testing something that was cut from the requirements. Is this my responsibility? Most of the time, yes, but I'm going to forget sometimes and it would be nice to know that it's not going to cost someone a whole day (especially as we are working remotely).

Estimation - none of the built-in velocity tracking has ever been helpful. I think this is because the cards are not atomic enough. Let's say you have a feature, "Add a new table to user home page", that requires frontend and backend work, database changes, dependencies on both sides (packages), spinning up environments for QA, and lots of unit and integration tests because this will be a core feature in the application. The project ends up taking 2 weeks but the question is, how was this work distributed? Did it take a week to implement the javascript package so that the user could filter rows in the table? Did it take 3 days for QA to spin up a new environment? Quantitively you won't know because all you'll get is a start date and end date from the software. You have standup, you can talk to your developers offline, but this information is not retained well, in my opinion. If I'm going to make reliable estimations for our organization I want to know how much each component took so I can plan accordingly in the future (or cut scope because I know certain things take more time than they are worth).

Documentation - as a developer I was not very good at adding documentation. The times I did, it ended up being very helpful. The other times, I would get the same question over and over. I believe that since code is written off of requirements in cards, the cards should serve as documentation but from my experience that's never been the case. You can see that a card was completed, but a) you don't know if it's the most recent iteration of a feature and b) what I mentioned in #3 are a few reasons why cards are not reliable documentation. Again, I think something visual would work better, like a flowchart, that is kept updated automatically when changes happen.

I am technical cofounder looking for a 50/50 cofounder(s) to help solve these issues. Any experience is ok provided you are willing to hustle. Currently doing user interviews, so the grass is very green and you will help design the MVP. Looking forward to making some connections.