I founded a startup that struggled with product quality, as many software businesses do. Despite our best intentions, our product was slow, feature-lite, and riddled with bugs.
As we struggled to dig ourselves out of our hole, I defined what I called The Paper Cut Problem.
Our product suffered from issues on multiple fronts. It felt like death by 1,000 cuts. We had macro issues exacerbated by micro issues – minor details that individually were not a problem but, when experienced together across our app, coalesced into a lack of product quality and polish, especially when combined with macro problems (tech stack, features, GTM).
Our primary product was a B2C mobile app, where quality and polish are paramount. From a business point of view, a lack of product quality and polish was an existential threat to our survival and, ultimately, contributed to our demise.
As I considered bridging the gap to where we needed to be, our Paper Cut Problem became evident. In addition to our macro problems, we had a significant backlog of paper cuts that needed fixing.
Should I divert engineering resources from significant issues to solve minor problems? Especially when there were so many of them, and none alone would solve our product quality problem.
And worse yet, even if I were to decide to divert those engineering resources to fixing paper cuts, there was another problem entirely: documenting hundreds of minor improvements, formatting them into Linear cards, and distributing them to our engineers.
To start, I created cards that were as sparse as their subject matter. They consisted of no more than a title, a screenshot if needed, and a handful of words describing the issue and necessary changes.
Our engineers did not like this approach. The lack of precise requirements slowed them down – requiring them to ask me for clarity, burning time they could have spent engineering. They pushed back, requesting more detail in each card.
That mostly ended my efforts to solve The Paper Cut Problem, at least at that point. Shortly after that, we chose to wind down our startup, deciding the competitive environment and our product shortcomings combined for an insurmountable challenge.
After that experience, I joined another startup as a product manager. Not long after joining, I found The Paper Cut Problem had followed me – we had fewer macro issues than my startup, but plenty of minor problems were degrading conversion rates and customer experience.
Frankly, I was resigned to the issue at that point. There were more bugs and minor improvements than I could document well. We burned down the list slowly but nowhere near as quickly as I would have liked, especially in a fast-paced startup where every second counts.
Engineering wasn't the bottleneck – product management was.
For a long time, I didn't have a solution. That was until recently.
On a whim, I threw together a card generator in ChatGPT. I built a multishot prompt that used a few high-quality cards I had written as examples, asking the AI to take natural language or "lazy requirements" and turn them into high-quality, formatted cards.
To my surprise, it worked like a charm. I could enter natural language like:
when the user types in the notepad, turn the generate button the primary color #5260FF
And the AI would respond:
## Overview:
The goal of this card is to change the color of the 'Generate' button to the primary color #5260FF when a user types in the notepad.
## To-Do:
• Detect input in the notepad.
• Change the 'Generate' button color to #5260FF when user inputs in the notepad.
## Acceptance Criteria:
• 'Generate' button changes to the color #5260FF when user types in the notepad.
• 'Generate' button reverts to its original color when notepad is empty.
My original "lazy requirements" would be insufficient for development in many teams – informal and incomplete. But, based on those "lazy requirements," the AI's response is well-structured and includes ACs, a to-do list, markdown formatting, and a description.
Those "lazy requirements" were my original solution to The Paper Cut Problem – the style of cards that generated pushback from our engineering team. My new solution, cards generated from natural language using this custom GPT, didn't suffer from the same issues.
I was so impressed by the POC that I created this website to share the tool with more people. It's free to use and intends to illustrate the benefits of card generation and, more broadly, requirement generation, even in its simplest form.
I designed the Card Generator to be easily bookmarked – much like WeTransfer back in the day. A no-hassle, "make your life easier" website. I hope it is as valuable for others as it has been for me. I use it regularly, including writing requirements for improving the Card Generator itself—very meta.
If you want to have some fun, ask it to "unsink the Titanic" or "make macaroni."