What QvikList is really about
I am in a funding meeting with many other IT leaders, looking to get approval for 25K for a small project. Someone’s questioning — how will you prove this paid off? Who’s the user? What’s the real benefit? Will people really do this? People with much less passion for our company throwing pitchforks, as I tried to ask for as little as I could possibly do something meaningful with. I had found others who thought this made sense, and were willing to make it a success, but people change hardly.
My idea was simple — create a repository of all the interfaces that existed between systems and just add to it when you’d create or change a feed. Normally, we would spend 4–8 weeks on projects just documenting what existed, so we could figure out what needed to be changed. I wanted to have living documents in a shared repository, so we didn’t recreate it each time. This would save time for projects and equally importantly time for people to remember and reconstruct what was being sent in data files and what system was talking to which other one.
This situation wasn’t unique. Over time, I saw other enterprising people who cared come forward with ideas, all asked similar questions, and pushed aside by a governance mentality that’s decried in trade literature. These were all people who I connected with, people who wanted to make things better, out-of-the-box thinkers. They say you should not give a damn and just do things and ask forgiveness later, to be successful in a corporate environment. And perhaps that’s true. The ones that were senior had developed thick skins, used to working around and through the bureaucracy.
The problem isn’t anyone’s to take blame for — companies have limited resources and they need to make sure it is spent wisely. It requires strong leaders to push change through. So creating barriers to change is almost a positive — it weeds out ideas that don’t have a chance to surviving the push-back and inertia that any change effort runs into.
Paving the Beaten Path
My company, like most, implement a strict governance process. The ‘governors’ are constantly guessing what will work and what won’t. It’s gotten a little better with Agile — where you get some money to show some value and based on that, you can do more. In the start-up world, entrepreneurs get to do something, and then what succeeds, succeeds, and the crappy ideas get abandoned. What works in the real world is the ‘pave the beaten path’ — let people try stuff and then double-down where you see traction (‘the beaten path’ quite literally).
I wanted to be able to shepherd my idea to a beaten path. Understand what was working and what wasn’t. Ultimately, I was just asking for people to collaborate, and not just with some unknown person(s), but with their teammates. Do something now that was going to help you or your teammate a year later. It was definitely going to help the company and it wasn’t increasing the amount of work, just putting structure around it.
The issue was that people didn’t believe that without a heavy hand, people would actually do what was required to help themselves later. I felt it was the lack of appropriate collaboration tools. If people see a beaten path to getting their work done, they’ll take it.
Kicking off the shore on a balmy day in calm waters
So I sought to create something that could enable people with ideas at companies to starts lists of information — to create communities for collaboration. People want to share and if they had a way to do this — it could be powerful. Some use cases I focused on: budgets, product lists, project lists.
The biggest problem I felt was if you left it open for editing (like a spreadsheet) — you ended up with too many inconsistencies in the information (when stuff got in, how often it was updated, what did a field mean “who’s really a project owner”, different uses for a field value “what does completed really mean” to name a few). And if you put controls around it — you got something nobody bothered to look at because it was hard to get to it and massage it how you might want to.
As I built this, I met with many potential users to get feedback. What I got was inertia. Why wouldn’t I just use Excel/Google Sheets to manage information. I mentioned that this isn’t a replacement for a spreadsheet, which is typically the output of a very small group. It’s what you need when you’re getting input from more than a few people. This is where companies typically buy custom software. Software that’s too hard to use but for a specific function and people have learned to live with crappy software pushed by one department when you’re working in a company. I sought to create a single platform for collaborating on information, something that various people and groups could make their own in the ways that mattered, and still make it easy for the user to become productive, without training and change management.
Finding the way through the forest
I wasn’t fully sure what it would take to get to something that felt like to really solved the problem. There are so many use-cases, each one nuanced. How could we deliver a product that wouldn’t just end up like many other specialty pieces of software? Something that could truly be universal, so when someone adopted it — they knew it would work for them. And when a company adopted it — it wouldn’t end up just solving some corner case. I had to build a core set of features so QvikList had broad applicability. After all, I was trying to turn the tide on all the money companies spend on non-core technology, to essentially shuffle information between people in a managed way, and get input, approvals, or just share so they can make good decisions.
It needed to be different enough from a spreadsheet, both because a spreadsheet was created 40 years ago and frankly still looks the same and does mostly calculations and capture information without a layer of control. It needed to have document storage capability, since there’s always information that’s going to remain in specialized files. Today, documents are stored in all sorts of places, but they rarely live side-by-side with the information they tell the story about. An account record doesn’t link to the account agreements that might have been signed. Emails live on a separate island, from the invoice that you’re trying to get paid. Today, so much is disconnected, and we’re trying to bring it all together.
Slowly, we started to understand the core features that felt like a whole solution. Not every single feature, but a core of them that would help someone to feel how empowering having access to all the information could be. And get a glimpse of the possibility that an information collaboration platform could solve so many different purposes practically that it would be hard to forget once you’d experienced it.
Chop, chisel, grind, polish — It needed to feel good, look beautiful
Once we believed we had a path ahead, it still required enormous amounts of what I’ll just refer to as perseverance to continue. Using QvikList didn’t feel effortless. It felt like you were being forced into a spreadsheet, which was absolutely not what users want to feel about most types of info. We had the notion of a team, but users didn’t want to first create a team before they could get to creating a list of the agenda items for a conference. How would you get back to something you created — what was the link and navigation path. In the 2 leading chat products, there’s teams and channels, which is pretty simple, but even in Slack, they needed to step out of that into direct messages. If we wanted to be the place people put whatever information they wanted to capture and share, it needed to feel simple.
An important element was the single-click. When the user does something and it works, do you inform the user what they tried to do was successful, or just close the dialog out. We were tackling a problem space that meant the user would very often use QvikList and so it needs to feel effortless. In some cases, the task is infrequent, in which case there’s more leeway to allow for a second click to close out the item, which we do if something is super important. When closing out tasks, we still require the user to open the task, so they can see what happened, before being able to close it out. Most other times, when you’re doing something, there’s no positive confirmation, but of course if something goes wrong, we’ll stop and show it.
Another point of multiple iterations was dialogs. When do you open a pop-up vs, just showing it in-place? When do you show a blurred background vs leaving the dialog in the fore-front but without blurring the background? Should the dialog be close to the button that initiated it or it be a separate page or be in the center or slide from the right or left? While these seem mundane, using the product felt very different when we left the context in-place and either opened the dialog close to the item or on the same page. We ended up with different solutions for different cases — so we could allow the user to focus fully for an interaction that’s more involved, vs. something that will result in a quick response.
I’ll share some comments about our workflow capability. We have tasks for simple requests (can you do this, or can you approve that) vs. multi-step tasks. Workflows are very powerful, and you can create a process from petty much any type of data. You can assign different steps to different types of recipients, and verify information along the way. Both ultimately enable that you can have an audit that something got done or just act as a reminder, so the person can drop right into the work. Simple to-dos and approvals needed to be basic but quick and handy. I believe we’ve nailed the workflows, but simple tasks still need work.
Security has gone through tremendous iteration. There are so so many models and complexities around who can and should see what and how to specify that while keeping it simple. So much software today either breaks down on the security front so you keep information in silos since you can’t easily share it. Or you have an open system and then follow it up w/ constant audits. Both don’t work. We have put a security model in where you can get specific or just rely on the defaults that will be safe. Our goal is to be able to bring as little or as much security as required, without forcing that mental effort upfront.
The final bit of commentary about the product I’ll put to paper for now in the core which I believe we nailed from day 1. When you’re collaborating with numerous people, it’s important to know who changed what and even be able to go back. Using GIT as the guide, we created a very robust solution for capturing the version history of changes. It’s like the multiple layers you’d see in a tree trunk — each ring tells a story of the past, is never erased but the tree keeps growing. Our thought around information is similar — it keeps changing but it’s sometimes important to know what it looked like before. Nothing is lost. The underlying system has the ability to have branches, so you can make multiple sets of changes, but only incorporate into the main ‘branch’ what’s needed. We ultimately decided not to expose this capability to user, but I’m sure we’ll need to revisit this at some point.
QvikList has gone through more iterations than I care to remember. The look has also changed numerous times, the colors, the fonts, the terminology, the icons — literally everything you see has been polished. Nothing is ever really done, but one thing you’ll feel is the product feels easy to use and simple to understand.
Onward and Upwards
We look forward to improving how people manage, collaborate, and share information. This ultimately opens up human creativity, so employees can act on their ideas more readily. It also simplifies collaborating with customers. If we can enable customers to contribute to product development at companies, that’s a collaboration that can pay off meaningfully.
