An experiment in design by democracy: Tech Plz
As a product manager I face a problem many of us face: How to capture the needs of our users, make sure we’re building the things they want, and make them feel heard? All whilst being a small team and with an endless list of work to do?
We recently tried a radical experiment in design by democracy and have seen incredible results: we’re 100% certain we’re building things our users really want, we have 10x as many people’s opinions guiding our features, users report greater levels of satisfaction with our team’s work. Best of all, we have more time to build features: this is all achieved by software.
The challenge of user-centric design
At SketchDeck we’re enthusiastic practitioners of user-oriented design — both in our graphic design service, and as we build our company and technology.
A quick introduction: We’re a design service, used by marketing teams to make their content look great. We’re trusted by some of the world’s best companies and have clients and designers all around the world. We’ve built a platform that brings all of these people together, delivering an exceptional service.
As I discussed in an earlier article, we let our engineers decide what to work on, which works because they practice user-centric design. Our company is about 70 people now, including our remote design teams. At this scale, user-centric design requires a lot of talking, communicating and coordination. If you talk to a designer in South America, how do you know if you’ve captured the needs of one in Korea? And how does anyone know what you’re planning to build?
This is concentrated by the fact that we’re a tiny product team: A CTO and an engineer. Besides writing software we do tech-support, hiring, maintain dev-ops and even run accounts receivable.
Visiting our clients, shadowing our designers, sharing learnings and communicating our roadmap would be a sizable job for a Product Manager — we have to fit it in beside doing engineering.
Whilst soliciting feedback from the company, people told us they didn’t feel heard. They were worried that their feedback to us would just get lost, that it “wasn’t in a list somewhere”. They asked us “what is the prioritization process?” and our answer “we decide by gut, based on conversations” wasn’t reassuring enough. We had to change something.
Being engineers, our first instinct was to see if technology could solve our problem. For a long time various members had bandied around the idea of having something “like Reddit” and I’d tried to use some off the shelf “idea capture” platforms (I found them too awkward and there were too many friction points for our platform users to use them). One evening, feeling inspired, I decided to write and release whatever incarnation of this idea I could.
It’s always remarkable how quickly you can build a basic technology product. Within a night you can write an Instagram clone, however it’ll take you all the effort of Instagram to refine the usability and scale to the point they’ve got it to. By the end of the evening I’d launched a basic Reddit style voting board. Within a day I’d added comment threads, notifications and different ways to view the board.
We included a brief description and a commitment from our tech team:
Our commitment to work on the top item each month is really important. This is not simply a place to be heard, it’s also a place to take action. It stays relevant because we keep building what it tells us. What is written in it will have a tangible impact on all of our lives.
Aside: The balance between design leadership and polling
It should be noted that Tech Plz is not the only arbiter of what we build. As with any leadership role, there is no single right answer and no single way to solve things. Tech Plz plays a complementary role to the other forces in a product manager’s life: company priorities, business realities, pleas from important users and visions for the future. One part of our product strategy is to continually improve our design operations, and Tech Plz is a great source of ideas and progress on that front.
The launch of Tech Plz
As you can hopefully see from the screenshot above, the tool is active and popular. Within a few days a rich collection of ideas had developed and clear favorites emerged. Every team-member knows about it. The top two items keep chasing each-other’s votes like steeple horses.
The TechPlz experiment has been incredibly interesting to me as a Product Manager. We previously had a roadmap (albeit one never communicated enough, and decided by a small group) and TechPlz has generated a list 80% similar to that roadmap. Exact prioritization of items and their phrasing is different, but the same items are at the top and bottom. This reassures me that we have been effectively listening to our users.
Despite the similarity between our previous roadmap and TechPlz, I am deeply grateful for the the transparency and infallibility the tool brings. I worry less about whether I’ve forgotten what people have told me last month, and worry less about whether I’m over-prioritizing recent events. It keeps our users’ views safely noted and keeps a fair tally.
Reflections after four months
We’ve now had TechPlz live for four months and been working through the items on its list.
We get some regular complaints about TechPlz, that “we’re not transparent enough” and “why can’t we work on more items per month?”.
The first comment is interesting because we’re totally transparent. We do exactly what the page says we will: work on the top item. We have a status that shows it’s “In progress”. Where this falls down is that it can take us longer than a month to work on these. And as progress is not instantly observable, our users lose faith in us and believe we’re secretly doing other things behind the scenes.
To address this, we’re hiring more engineers to speed up our feature development, and we try to communicate as much as possible about our progress.
Overall, I see this as a good problem to have: our users really care about the things in this list, and are pressuring us to deliver faster.
Despite the aforementioned challenges, TechPlz has been a positive and enduring addition to our product management process. Having a stable, self-organising list of user requests frees me up to spend more time on researching and building the features requested. It also enforces and demonstrates our commitment to listening to our users and building what they ask for.
I hope you enjoyed reading this — as we try new things and learn from them we’ll continue to post those experiences here on Medium. If working for one of the most innovative design services in the world interests you, check out our jobs page, we’re hiring.