The aha moment that led to Trello, says its creator Joel Spolsky, was a series of "customer visits to see how people were using Excel."
His findings, gleaned while Spolsky was a program manager on Microsoft Excel team in the early '90s, won't surprise you. People didn't do much calculation in their spreadsheets, but they did a whole lot of 2D layout. Excel was, and remains, a great example of a user innovation toolkit -- a product that's malleable enough to enable its users to reshape it according to their needs.
Trello, not coincidentally, is another great user innovation toolkit. That's true broadly: Trello is a project management application that's used to plan weddings, plot novels, and coordinate housing searches. It's also true in the narrower realm of modern software development where Kanban-style boards dominate our walls and our screens.
Trello supports the popular idea that software development tasks are represented on cards that move across columns on a board, evolving from ideas to specs to working code. But it doesn't prescribe any particular methodology. Kanban? Scrum? Scrumban? I'm not entirely sure what those terms mean, but thankfully Trello doesn't care. It's an all-purpose toolkit that provides a few basic building blocks: boards, lists, cards.
Teams need to figure out how to make best use of that toolkit. One of them, it turns out, is to evolve a workflow that makes sense to everybody on the team.
After several rounds of negotiation we've come up with an approach that makes sense to us. The names of the lists on our board aren't conventional. For example, we no longer have a list called Backlog. The processes that we represent on our board are universal: idea capture, idea refinement, prototyping, development, deployment, support, bug triage. But the ways in which our team enacts those universal processes are highly specific to our product and to our mix of personalities.
Every team workflow is unique. We've used Trello to hammer out a team consensus about what ours should be, and it has been invaluable for that purpose.
As we refine that workflow, Trello's generality becomes less helpful and we begin to feel the need for features that Trello lacks. Cards in Trello, for example, can't spawn children that remain linked to their parents. That's becoming a common operation for us. A card in the idea-capture phase will include discussion of the idea and will link to specs and related documentation. That idea card may spawn three or four new cards as we move into the refinement phase. We want those children to link back to their parent, and we want the parent to link to its children. Though doable manually, it's tedious.
You might conclude, at this point, that we've outgrown the tool and should switch to one that automates parent-child linkage. I'm resisting the temptation. We're not dealing with that many cards, and it isn't too hard to manually split them apart and link them together.
What's more, I've done enough hacking with the Trello API to know that if I really need to automate that splitting and linking, I can. That's another way in which Trello shines as a user innovation toolkit. While I imagine that I'd want Trello to offer parent-child linkage, I'm still not sure precisely how I'd want it to work. Also, your notion of that will differ from mine. By enabling all users to simulate the feature manually and by enabling API-wielding users to simulate it programmatically, Trello meets our needs well enough.
At the same time, crucially, Trello lays a foundation for improvement. Our manual and programmatic adaptations, across a broad range of uses, provide the best kind of feedback to guide the future development of Trello.