Whether you’re struggling to improve your product, juggling too many conflicting feature requests, or facing growing levels of competition, a values-based approach to looking at those problems may provide the solution you need.
Values-based Product Design
Design ideas can come from anywhere – user research, ideation, a shower epiphany, brainstorming, a dream. You won’t implement most of them, luckily, but that doesn’t mean that they aren’t useful. Why and how we reject ideas becomes an important part of company culture. It also is a building block of brand personality and character. And after all, the product itself is just an artifact of the company culture.
From the moment Kanbanery was live, I’ve been getting feature requests. My relationship with feature requests has changed dramatically over the years. In the early days, when there were just five of us building frantically and feeling delighted to have our first hundred, then thousand, and then ten thousand users, I thought of feature requests as work orders. Stuff I had to do to keep those people happy. Now I hear them only as cries for understanding that I can often address without writing a single line of code. Often there are non-technical or third-party solutions. Sometimes all they want is a bit of sympathy.
As Mike Burrows illustrates so well in his book, blog, and conference talk, the Kanban Method rests on a set of core values. The biggest barrier to implementing a Kanban system is when the values inherent to the tool clash with the values of the company or team using it. How is a secretive team that doesn’t trust others supposed to make all their work visible? What attracted me to Kanban in the first place was that it meshed so well with my values. As the founder and president of Lunar Logic, I’d built a company that reflected my values. I had employees who either shared those values or at least functioned well in an environment modeled after them.
How do values impact product decisions? The easiest answer is to share a few examples. A frequent feature request is to add employee-level metrics. “I want to see who is putting in the most time on tasks” or a common request is “show me cycle time by person.” I’ve always refused and replied that Kanban is a tool for improving systems, not for stack-ranking employees. Improvements should be implemented at the system level, not at the unit level (look for a future post from me “I don’t believe in lazy people”). Systems thinking (or holism, as it’s called in my first discipline of anthropology) is important enough to me to lose a client over. I’ve resisted any feature that could be used to blame or judge an individual. That same value has led me to reject custom board views for individual users. A team can’t collaborate on improving a system if they don’t share the same view of it.
Respect for People
Another core principle Kanban and I is respect for people. How does this value express itself in Kanbanery? I respect people’s time, so our onboarding emails are as concise as possible, with no marketing fluff. The estimated reading time is always under two minutes, and I include it in the subject line. I send it from my personal email address, so your replies come straight to me.
We would like people to visit their Kanbanery board often, but we won’t trick them into doing it like so many other SaaS products. When we send a notification about a chat message we include the full text of the message. I hate getting emails that read something like “You’ve got a message waiting. Log in to see it.” That feels rude to me. If you’ve got a message for me, give it to me, and let me decide if it’s worth logging in to react to it now or not.
I don’t believe in technical solutions to human problems. If a manager doesn’t trust her team, the solution isn’t to place limits on what they can do. Doing that violates my principle of trust in people. That’s why I reject requests to create rules that only let certain people pull tasks from a column, or change the owner of a task. A physical board works with no such rules. There’s no way to keep someone from walking over to a wall and ripping up a Post-it note, moving tasks backward, or changing an estimate. To place such rules in Kanbanery would be like agreeing that it’s okay not to trust your team. It’s not. That’s a problem, and the solution isn’t more control.
I value transparency. I think it’s a core component of creating trust and essential for effective collaboration. When I was running an offshore web development company, transparency was my primary answer to everything. I remember the first time one of my employees made a mistake and wasted a day’s work. He asked me what he should tell the team (including the client) during the stand-up meeting. “The truth,” I said. A client will never find a team of people who never makes a mistake, but a team that will tell them the truth, all the time, even when it’s embarrassing? That’s priceless. And that’s why in Kanbanery it’s impossible to hide content from anyone who has access to a board. People have asked for it, but I won’t do it.
That’s also why Kanbanery is the only Kanban application that lets people download the raw data we use for metrics. A metric is worse than useless if you don’t trust it. So we share the data and the calculations so that people can import it into a spreadsheet and test it themselves, or tweak it and form their own conclusions.
It was a few years into the life of Kanbanery before I realized how those values were shaping the product, and a few years more before the opportunities that approach presented became clear.
Programmers make many small decisions in the implementation of a feature that aren’t part of the specification. Many of them are never discussed with a product owner or product manager. Some only show up in edge cases, so they may not even get tested. At the team level, being clear about a product’s principles helps everyone to make better and more consistent decisions.
It also makes it a lot easier to explain your choices to users. When I reject a feature request on the basis of one of our values, some clients understand and consider changing how they think about work. Even when they don’t share my values, they always respect my decision and appreciate my explanation.
But there’s another huge value to principle-driven development that I’m just beginning to see myself. When we built Kanbanery, we were doing it for ourselves and people like ourselves. It was a tool for software teams, and especially distributed teams like ourselves. There are millions of them, and if they wanted an online Kanban board, they had to choose between three options, all built and released in the same year. The tools were different enough that we could all share the market with plenty of room to grow. But coding a Kanban application isn’t rocket science. A single programmer can make a basic online Kanban board in a day. And so now, eight years later, I can’t count the number of competitors Kanbanery has, and more are always emerging. If we’re all targeting distributed software teams, that pie starts looking smaller, as does the distinction between the competition.
Redefining Market Demographics
But what if we change how we define our market? What if Kanbanery is a productivity tool for systems thinkers who value transparency, trust, and believe in treating people like adults? That’s not only a much bigger market, but there’s no one else targeting it.
Now almost half of the people I’ve spoken to who use Kanbanery aren’t in IT at all. They’re songwriters, professors, construction workers, bankers, dentists, and hospital administrators. They’re discovering innovative ways to use Kanbanery that I wouldn’t have imagined. What does a dentist in Maine have in common with a project manager in Bangalore. Perhaps they both found the right tool for them because they share similar values.
By designing a tool based on principles and the metaphor of a physical board, we inadvertently created something as universal as the Post-it note or whiteboard. That’s much more powerful, and marketable than the ideal tool for distributed software development.