Trello co-founder Michael Pryor on pandering to power users
theregister.com
theregister.com
> Pryor reckons one pain point is visibility into the increasingly busy Trello boards put together by customers, but the team is cautious about sacrificing usability on the altar of feature requests.
> "Developers," he said, "add more stuff, add more stuff, add more stuff... and, essentially, you get this tool that does more things for those specific power users. But in the beginning, those people that were using it, you've now turned those people off, and they're not coming in anymore, because now the software is too complicated to use."
I didn’t fully understand this as a developer, but it become crystal clear as a product manager. I personally love power tools with countless knobs to adjust, command line options to explore, complex features to learn, and other fun things that stimulate the mind of an engineer.
But the number of your customers who want unbounded complexity is very, very low. Some of the most vocal customers might mislead you on this fact by demanding some specific feature for their workload and recruiting armies of commenters to back them up. Letting the loudest customers dictate your product roadmap will start to alienate the silent majority of your users.
Offering plug-in functionality, a scripting system, or a documented API is a nice way to cater to power users without cluttering up the UX/UI. However, that brings up a real problem with the power users who think they know more than they do, who end up destroying their data through the API and trying to have customer support fix it or otherwise hold the company accountable. It doesn’t take long to realize that you’re simply better off letting the 1% of power users feeling disappointed while you focus on a product for the 99% of users who just want your core functionality.
20 years, I still dont understand how most developers dont understand. I guess that is the difference between a developer mindset and product manager mindset.
And hence why lots of startups failed.
Devs have to deal with all the bugs and messy codebase
It’s promotion-driven-development.
I generally feel that most things are best when they are in some kind of healthy tension. Appeasing power users happens because it appears to align with both of the above.
Look at the tools developers use throughout their careers: Powerful version control systems that support nearly every operation you could imagine. Command line tools with pages and pages of documented switches. Server software with configuration options for every little thing you could ever want to adjust. Well documented open source software that can be changed to your liking with a simple fork. Websites full of fellow developers freely asking and answering almost any question you might have.
When dealing with complexity is the story of your career and you spend 40 hours per week doing this for years on end, it's easy to forget that your customers aren't in the same boat. Most of your customers are using your products to get their job done. They want to learn it quickly, get in, get out, and get back to their work as quickly as possible. They might not even know if they're going to use the same tool at their next job, so taking time to learn it in depth isn't appealing.
As a professional user, I bought a $2,000+ workstation. I expect the applications I run on it to be powerful tools, not toys. But, there are also plenty of other people who run apps on $200 mobile devices who are fine with fewer features. Pick one market and go after it.
> Most of your customers are using your products to get their job done. They want to learn it quickly, get in, get out, and get back to their work as quickly as possible.
This is true, but a missed opportunity. Many people could benefit from more powerful tools to do their work more quickly than currently possible. The "get back to their work" part is the dissonant part; the reason the power tools work for developers is that using those tools is our work, not something we have to leave to get back to it. This should be the case for more people than it currently is. It is not just developers though, there are really powerful tools for a bunch of high-leverage fields, for example image, video, and audio editing, and many different jobs in finance. A lot of the low hanging fruit may have been picked, but I suspect there are huge industries where this sort of thing is still ripe for picking. For instance, I still constantly interact with professionals using awful underpowered tools for their very specialized jobs, for example lawyers, accountants, and teachers.
So may be it's important to understand your target audience.
Of course some people just hate their job and the only thing that makes them happy is the end of the day...
Remember, as someone on this forum, you're on Over Achiever Central.
That's their own fault IMO. Power users by virtue of their name shouldn't need babysitting.
In practice, you can't simply divide customer problems into self-inflicted and company-inflicted and decline to support the customers' self-inflicted problems. The line between the two types of problems is too blurry to enforce, but the reality is that customers don't care either way. They just want you to fix it, and they expect your product to prevent them from shooting themselves in the foot in the first place.
Almost all orgs I know which were at first happy with Trello, eventually had to move to something more powerful. Jira used to be the default choice, but in the last year I see a lot of movement towards ClickUp, which I think has a good combination of simple defaults and powerful customization.
As such, I'd suggest Trello try pandering a bit more to power users - if for no other reason, then because if they don't like your app, they'll advise their less tech savvy friends to stay off it too.
I admire Trello's desire to keep things simple. I think what you're overlooking is that software is eating the world and if people shy off Trello, who cares. They are not going to run out of customers. We haven't hit a plateau of software projects in the world. And people that trade productive effort against the project for power user fun are probably going to hit a point where the burden of their reporting needs on the project becomes visible to everyone doing the work. (If I sound jaded, blame jira).
Usually power users and their dashboards feed back into projects arcane and fragile rules around how tickets are marked, categorized and written all for the better visibility. I think this is a project anti pattern, it's like the song that plays before the death march.
Generally, I think managers are looking for a magic bullet for complex project management. They are thinking that a some uber reporting and dash board vomiting software package will save them. I know it won't.
I have Visio, but I sure do use WebSequenceDiagrams a lot and enjoy the speed it delivers me with it's focus.
Perhaps. But then I feel there's a big hole on the market, something desirable by both individual contributors and product managers. A lightweight ticketing/work planning system that supports certain (arguably fundamental) task management features like:
- Infinite nesting (not just 1 or 2 levels).
- Fast adding of tasks
- Modelling tasks as DAGs, not trees. That is, allowing for proper dependency graph between the tasks.
- Allowing entering both absolute and relative time estimates ("start: 2020-11-01, end: +5 days", and "start: N/A, end: +5 days", where "N/A" means "once all dependencies are complete").
- Turning said task DAG with estimates into a GANTT chart.
- Turning said task DAG into a PERT chart and computing the critical path.
Seriously, the last three are kind of fundamental if you want to do some kind of scheduling around planned work, and yet I haven't seen a single developer-oriented product that could do it. I'm not pulling this list out of my ass - this is what we came up with at my previous job, and we spent time looking for a solution implementing even a subset of this. But for some reason, it's become a religion in our industry that tasks shall form trees, of depth no larger than 2, and GANNT and PERT are for PHB MBAs and not for self-respecting developers. sigh.
If I wasn't a busy parent with a job and a videogame to write, I'd probably write this myself.
The most difficult part I think would be to make entering graph nodes ergonomic. In my experience, these kinds of tools live and die by the speed at which you can enter, modify and move things around in them. If you have to click a lot and type data in a bunch of forms, developer won't be using it.
Example: that time when I first compiled the list of desired features, we were trying out YouTrack from JetBrains. My co-worker liked it, but found entering subtasks annoying. I wrote a little script inside YouTrack that turned every Markdown checklist into new tickets, backlinked to the parent one. A total hack, but made a big qualitative difference in terms of working with the tool.
The key two principles for me therefore are:
- Fast to enter and manipulate data in it. Everything doable from keyboard, and little waiting for things to process (hello, Jira).
- Embrace the fact that plans and work subdivisions keep changing all the time. Allow users to restructure their tasks, warn them when they affect other parts of the graph, and just persist the changelog so that a broken graph can be easily fixed.
I have some more ideas in this space, but little time to deal with the surrounding work that's required to turn it into an application prototype.
Most systems I've seen allow you a one top-level of Task (under some "project", "epic" or whatnot). Then you can - in some - add a kind of degenerated, impotent Subtask to that task. And then your next level of nesting is just a humble bullet-point checklist.
What I want is truly composable Tasks. Because sometimes real-world work expands like that. Because I want to subdivide my work within the ticket I'm assigned to. Because sometimes I don't know how much the entire ticket will take, but I have a pretty good estimate on what the subtasks will take, so I want to input that, and then both me and my manager will have a ticket estimate that's a little bit less nonsense.
The DAG part enters the picture here: I want to be able to have tasks depend on each other. I want to be able to make a top-level ticket depend on a sub-sub item of another ticket, because sometimes your co-worker can start working on their part once you do one small part of yours, and it would be nice to have that information correctly recorded in the system (instead of Task B being blocked by the entire Task A).
(I talked about nesting before, but the truth is, with a DAG, nesting stops being a first-class concept. It's just a matter of presentation, of which you could offer many types - but underneath, it's all just a graph of tasks that connect to each other. A simple and elegant model.)
Now I know that there's a lot of software "agile" philosophy that essentially makes you implement that DAG in your head. No point of cross-subtask dependencies if your agile dogma tells you tasks need to be small. No point in complex linking if half of it won't fit in a sprint, etc. But that's using philosophy as a hack around inadequate tooling.
There comes a time in a team's life where you want to plan out some complex work that spans multiple stories/epics/whatnot. Many months. Tooling for that is scarce (and this is how we discovered the desired features I listed in the previous comment). But I see no reason why you should do that work on a different tool than the one you'll be using for day-to-day work. Imagine instead that, during a planning session, you subdivide work as deep and wide as you can, you link it all into a dependency DAG, enter initial estimates, etc. Then, day-to-day, people will adjust and subdivide and relink nodes as the work demands, but at all times, the entire plan, the entire schedule, and the critical path, is visible to everyone.
That's what I want. A ticketing system that also works for project planning, locking day-to-day work and planning into a tight feedback loop - so that you have both high and low-level views available, and always in sync.
This is what I was wondering about. Please correct me if am wrong. If tasks are indeed modeled using a DAG, then there is essentially no nesting, right? What we think of nesting in the traditional sense can just a bunch of small tasks with varying dependancies.
The metaphor of nesting is a solid one - tree structure does capture a good subset of thoughts about task management. So I'd start with a proper tree of subtasks, not limited by depth[1], and then add the ability to link any other task as a dependency (as long as no cycle is formed).
You could expand the types of edges[2] to allow things like "optional dependency" or "starts when dependant task starts" to model parallel work. But I'd begin with just augmenting a tree with backlinks and surfacing the graph structure. And then providing GANTT charts and PERT analysis. I really do want to have the critical path be always computed and evident to the team, as well as available slack on each task.
--
[0] - I haven't seen a tool like that nor do I have working prototypes, so I'm all playing it out in my head.
[1] - I currently have such proper tree in Org Mode - and my tasklists tend to routinely grow 3-4 levels deep.
[2] - Instead of edge types, you could use node groups. Like, have "Task 3.a.1" represented as "Start of Task 3.a.1" -> [subtasks of 3.a.1] -> "End of Task 3.a.1", but multiple edge types are likely to be much easier to work with.
I still love Trello for its fantastic info architecture, the card interface, and the data I have in it, but I barely use it anymore because it's not as good at organizing as a database, and not as good at scaling to docs and projects as a tool like Notion.
It’s typically the case that for any powerful tool, any power user might use only 10%, but it’s often a different 10%.
The solution is to design a good on boarding process / learning curve which lets users figure out what subset works for them. Are we going to be forever stuck in the purgatory of having limited tools because the UX has to involve no learning/development (I.e. be “intuitive”)?
Contrast that with many popular SaaS products, which seem designed around capturing a particular workflow and building a shiny structure around it. This allows new users to complete the desired workflow with nearly zero learning - but then they can't do anything else. There's no space to grow.
It feels like a fundamental difference in thinking. Excel is like a box of tools. Initially you only need to drive a few nails, so you grab a hammer and start pounding. Over time, you'll figure out how to use every other tool around your house, swiftly and efficiently. Modern SaaS tooling is like Juicero. Beautiful on the surface, extremely inefficient and wasteful (and to think of all the engineering hours behind it!), and at the end of the day, all you can use it for is squeeze some DRMed juice until eventually the company folds and you're left with an expensive paperweight.
I mean, the number of products I've seen that would be more ergonomic if implemented in, and distributed as, an Excel spreadsheet, is getting too large to even call it funny. Sometimes a smart business embraces this analogy literally. Ever heard of Palisade? They're leading the information security risk modelling market, and their product is literally an Excel plugin. And, having worked in this space, were I a CISO, I'd chose them over the various startups that've been popping up over the years, simply on the grounds of ergonomics.
So by all means, design a good onboarding process. But it's good to have something to onboard people into.
(Excuse the rant.)
I wonder what the world would look like if the creators of the spreadsheet had this attitude.
Formulas are awfully complicated, after all - to say nothing of pivot tables...
As an example, Pivot Tables are an attempt at an "easier" UX for a very common sort of (set of) formulas: What is the "summary" here? What does this table look like "sideways", and is that a useful summary? (I've seen spreadsheets with manually built pivot tables in hideous formulas. Pivot tables really are easier than that mess.)
Formulas are what a spreadsheet user comes to a spreadsheet for. So most of the complexity of the spreadsheet "has to be there" for people to consider it a working spreadsheet.
That's a big source of friction for me as a developer because I know when someone asks "Can you make it more like Excel?" they don't mean "can you make an uglier data grid here" they more often really mean "how interested are you in rebuilding Excel's formulas engine, it's charts engine, and maybe it's pivot tables system, and a few other things I regularly use?" but they don't know that they mean it (because they don't understand themselves the tools they use, they just use them). Raw rectangular data grids aren't actually a very useful user experience, and a lot of users ask for them because they are familiar, but also a lot of them ask for them because they've got a head full of unchallenged assumptions that "computers are math machines, I should be able to just insert a formula here" without realizing it. More often than not when a user is asking me "Can you make it look more like Excel?" it's that there is some formula they want to run and asking the follow up questions what formula they think that is is often more interesting/useful than "make it look more like Excel" ever is. At least in my experience.
It's worth making a distinction here between complexity and flexibility, which I think some designers / product managers fail to grasp.
Users don't want complexity, but they do want flexibility, especially from tools they use all the time. It's a hard balance to make products that are simple and flexible, but the products that pull it off tend to rule the world. The humble spreadsheet software is the ultimate example.
For example: adding more whitespace and limiting the number of fields on a screen will reduce complexity for users, but it may also reduce flexibility and end up as a net negative. (looking at you FreshBooks, I'm still angry about that redesign a few years back!)
Setting aside the random naming and inconsistent argument placing, most UNIX CLI tools have sensible default behavior.
But you can man the tool and find a whole bunch of switches etc that offer up a lot of complexity.
The piping system similarly is brilliant. It’s a simple and easy way to make extremely complex workflows using simple tools, but you could spend your entire life never knowing about piping and still do just fine with the individual tools.
Comparing your guess with what you learn from the man pages is an indication of how inconsistent most of the classic Unix tools are.
I'm on OS X here, and I can't find any info about this at all in the man pages! I'd never really thought much about it; usually find is the very start of the pipeline for me. I have run into the -print0 option before though when passing the output into xargs :)
I think Alan Kay said it best: Simple things should be simple and complex things should be possible.
Excel is an example of software not meant for programmers that exemplifies this principle. Doing simple things in a spread sheet is simple, it doesn't take more than a few minutes to learn how to sum up some columns and manage a simple budget in a spreadsheet, but there is still a lot of room for power users to stretch their muscles. (Whether or not some excel power users would be better off hiring a programmer is another matter, but excel has doubtlessly empowered millions of non-programmers regardless.)
Making a complex thing simple is the goal we should strive for.
Edit: I forgot where I was going. Here it is: I don't understand why HAVING TO LEARN HOW TO USE A PROGRAM is such a terrible thing. I remember when there were books for things like Lotus 1-2-3. People learned.
Besides, a blank GUI with 10 kinds of swipe gesture isn't exactly "user friendly" lol.
Lotus probably had 500k users and Excel probably has 500m.
Meanwhile, it's not clear to me how a novice is meant to figure out 'three-finger-swipe-to-undo' on iOS but apparently iOS is the poster-child for intuitive friendly design...
It could be summarized simply as: decrease options, increase option depth.
Apple does this very well with its products. From the 'unboxing' experience, down to the dashboard UI's and functions. Every complex function is 'unfolded into', while only the things that are immediately necessary are made obvious.
I made a drawing to help to further illustrate this idea: https://twitter.com/PlanFlowDev/status/1311356383221223424/p...
Sometimes however it is entirely possible to "go sideways" sometimes. This is the Answer to the wuesrion: "Why not both?".
This approach takes however a lot more energy usually. More thoughts and modifications are needed compared to just quickly adding some feature. And sometimes there just might be no solution at all.
But we are talking about software. So even if there is no organic solution that gets you both, it might be totally viable to hide some feature in a "pro user" section in the preferences or something among these lines.
After all most people will not click into the Preferences, but very few power users wouldn't.
Power users need “user accessible parts”. Unfortunately we often either don’t scratch this itch, or scratch it with plugins on the server. Which means if I really want a feature, I have to inflict it on everybody on the team, as they inflict their preferences on me.
Having the app behave differently for five users is a bit too much of a combinatorics nightmare and most of us will run away from any such discussion as fast as possible.
With most things there is a middle ground that gets most of the benefit with a fraction of the trouble. I’m not sure I’ve seen anyone find it though. Or at least outside of video games.
As you mentioned, power-users bork their own data and power-users at big companies bork everyone's data at the company.
Another thing is that exposing an API makes you into a platform, on which third-party developers will try to build businesses. At this point you wind up having a small-scale version of Apple's dilemma. Third-party developers don't want you to encroach on their "turf" with first-party features, but it may be much better for your users if you're the one executing that feature. Third-party developers will try constantly to get you to do their jobs. You'll be locked into backwards compatibility in a way that you wouldn't be if you didn't have an API.
To be clear, this isn't an argument against exposing an API. Power users and their preferences are one thing, but another benefit is the ability to expand into foreign markets by partnering with local entities. If your software interacts with government regulation in some way, for example, it can require substantial interface changes and putting that maintenance burden on a third party more familiar with the government in question is a big win-win. This is especially true when you are in several markets, all with diverging UI needs - an API and local partnerships save you from trying to be everything to everyone.
I'm sure for some codebases this is true but are y'all not just giving customers (basically) the same endpoints you give yourselves/your frontend team to build your 1st party UI?
We built these empires. But then we get kicked out because stupid people are stupid.
Do we elevate these folks to power user status? No. Instead we stoop to their level, all in service of making more money.
Sick of watching tech (and people) functioning at a tiny fraction of their potential. We could be living in a beautiful world where people bend tech to their will, and not the other way around
First point of complexity that's always being lost: power users aren't born, they're made - made from repeated exposure. First point of nuance being lost: being nice to power users means having features available and discoverable; it doesn't mean you have to clutter your pretty, simple, polished UX with it (and so decide to not do the features in fear of design impact).
Why it matters? Because operating a lot of hot, hip software - like Trello - ends up being a dayjob for many people. If you're sitting 8 hours a day, 5 days a week, for years, using mostly a single piece of software, you're in a perfect position to become power user of that product, entirely effortlessly. If that software is "pandering to power users", then your work speed, quality and reliability will keep going up over time, as you get more proficient and efficient at using the tool. Whether you'll use saved time to rest, to slack off, or to get more work done - that's up to you, but you have a choice, and your employer saves money (whether through increased efficiency or reduced risk of employee burnout). Meanwhile, if the software embraces the "simple use only" principle, you'll just be wasting your life in front of a glorified Fisher-Price toy.
"Power user friendly" really means "leaving space for users to grow".
"stupid people" is also a strawman. There are plenty of smart people out there who just want shit to work. They don't want to fiddle with everything like power users do.
Medical/healthcare professionals are a good example of this.
This is part of the reason why iTunes beat WinAmp and that other player from Panic. It's why 99% of people buy cars to drive them, not to tinker under the hood on weekends. It's why people will pay for Photoshop and Windows, instead of using GIMP and Linux for free.
GIMP is arguably no more complex than Photoshop, it's just badly designed. And the UX is inconsistent with the look and behavior of pretty much every other app on Mac/Windows.
Popularity is the sum of a number of factors, and simplicity is just one of them. It may not even be the primary factor. I think we've had a bit of a reset, spearheaded by Apple, because bad UX got out of control, but phones are still gaining more features not less. We just have to make sure that the race for features doesn't get too far ahead of the UX teams having time to make it good.
I'm the opposite: my life as a dev is already so complex that the less knobs I have to adjust on a new piece of software the better I feel (then of course you'll hear me complain a few days later that if only I had the source of this app to implement this missing feature ;)
The flip side to the argument here though is that you get tools without much depth, and for certain markets depth is important. For developer tools, depth is almost certainly the right trade-off compared to simplicity, for example.
I think Trello is a great example of a project management tool taking the simplicity over depth approach. This is why my friends and family like it for personal things, and for small business problems, but it's also why I don't like it for work – because I work in a bigger team with more complex requirements and prefer something with more depth. I like Trello much more having come to this conclusion about who it's for.
For example: One could argue that Apple was brought back to life by a relatively small group of Power Users with specific requirements for their workloads (Graphic Design, Video Editing, desire for powerful Unix workstations and laptops, etc...) and Apple met those requirements in a way that no one else was able or willing to. Now that Apple's market share has increased - and more importantly, they have started to focus on computing-for-the-masses - you can clearly see why some Power Users are disappointed in this direction, and are feeling left out. Sure, Apple is wildly successful (in a way that they might not be if they spent more resources making that minority of Power Users happier) but it's obvious why those Power Users feel like Apple is leaving them in the dust (and Apple might not exist anymore today, had it not been for those Power Users).
Today Xubuntu makes for a better *nix environment (IMO) and Windows has better gaming graphics and backward compatibility. With WSL maturing there's less reason to have a Mac except to compile for the lucrative garden dwellers.
You could also argue that Apple was brought back to life by the iMac, which was decidedly not a power user machine. (Not easily expandible, USB-only, no choice of display, limited model specs, etc.)
Gnome 3 comes with a settings application that allows you to customize keyboard shortcuts -- on my laptop I changed the maximization shortcuts to Ctrl+arrow_keys instead of Win+arrow_keys, which is easier to press one-handed. Most people probably know this. What most people probably don't know is that you can actually assign multiple key combinations to the same action (say I wanted to add the Ctrl shortcuts instead of replacing the win ones). This option is not present in the settings application gui - you have to edit the corresponding dconf entry and add another entry to the array of shortcuts. This is somewhat cumbersome and the gui still only displays the first shortcut in the array, but it lets "power users" do something niche without harming the coherent experience of "regular users".
The real dichotemy, in my opinion, is between quality software and developer time/effort. And I don't mean to belittle developers here (I am one, after all); getting a split design like this right -- such that there are few leaky abstractions -- is HARD. I found out about the feature due to one such leak: there are a few shortcuts on Fedora that have two default shortcuts (changing workspaces with either Ctrl+Alt+page_up/down or Win+page_up/down), and changing the one you can see (Win) doesn't remove the other one (a problem for me, since I wanted to use the other one for something else, and I couldn't through the gui; I had to remove the second default in dconf first).
Finally, the air quotes around "power users" are because I think it is a leaky abstraction. It's not one group of people who want to customize everu feature, it's a larger group of people who each want to customize one different feature. I think the winning approach overall is to provide a few low level hooks into your application's functionality, that people can use to code their own tweaks.This allows you to get rid of the options that cover a tiny minority of use cases, without losing the functionality. The android todo app Simpletask gets this part perfect with its lua scripting, although the UI is not as polished as it could be given more developer time.
They used to be a small, privately controlled company with focused yet ambitious goals and an audacious vision (Build a company that will last 100 years). Then ~10 years ago they took a butt load of money, pushed big towards US enterprise and acquired what appears (to me anyway) a random set of companies that looked good at a specific market/time period but have largely faded away?
I find it quite mind boggling; there must be something going on beyond what I can see.
Why is Trello being blocked?
Never work in a heavily regulated industry if this type of thing bothers you, because it exists at every level of those companies.
Then you have to keep on them forever, and stay apprised of features people would like you to use but aren't FedRAMP appropriate yet or do not have appropriate controls. I think you would be surprised how many SaaS providers really don't meet the muster under scrutiny, or your engineering teams are trying to use features that just haven't been brought into compliance yet. For example, the number of times I have had to use https://aws.amazon.com/compliance/services-in-scope/ (click the FedRAMP tab) as a hammer is extremely high. Then you get on the phone with AWS and you find out that only a certain subset of the service that meets their FedRAMP do not provide adequate controls for your usage of the service. There's a lot of defer to vendor and defer to user games being played by both sides and you have to go line by line and figure out who is responsible for what. More often than not the service's people that are catering to the customer are not appropriately educated too, so there's layers of escalations by a security team just to get someone who can answer security questions accurately.
So no, a security person can only see from most organizations that you tried to attest to some of these random certifications, but that doesn't mean I have an accurate map of how I'm supposed to meet my compliance goals with your stuff.
(This is not aimed at any one provider in particular, just my personal feelings on where this 'internal roadblock' argument falls apart).
It becomes overhead for the teams involved in maintaining security and compliance. The cost of that overhead is likely several orders of magnitude higher than Trello’s relatively simple monthly fee.
If the whole company goes in on Trello, that’s one thing, but jumping through the hoops to get and maintain approval for a small number of people just isn’t worth it. That’s why the behemoth, everything-to-everyone tools dominate at heavily regulated companies.
Unfortunately Trello did not satisfy management because it didn’t easily give them metrics that serve little to no purpose other than changing the team’s incentives from encouraging a great product to meeting metric targets.
(And as I understand it, Trello Enterprise doesn't even get you SSO without paying additionally for Atlassian Access? The website seems to be inconsistent on this point.)
We have teams that would definitely like to use Trello, but $4200/month as the minimum tier was too much.
Trello Enterprise (optionally) would secure your content (i.e. attachment restrictions, power-up restrictions, token restrictions, audit logs, team management).
"Exclusive Enterprise Features: [..] SAML SSO via Atlassian Access"
Similarly, on the pricing page: https://trello.com/pricing - it lists "SAML SSO via Atlassian Access" only on the Enterprise column.
"together" meaning with the client... How did you do that if it was never approved in the first place? Or maybe they just realized they never should have done it?
It was a pretty confusing and vague quote, at least to me.
Users will sign up for Dropbox accounts, share the credentials with others in the company, disable MFA and them load it full of confidential data. Users will do things like using personal email addresses for apps that become critical to business processes, then quit without transferring the account.
Additionally as a European company, we are bound by the GDPR to know where confidential data is being stored and processed, to have assessed any third parties and put them in our data processing agreements.
Consequently we end up in this situation of having to be the bad guys, blocking otherwise useful sites with proxies/CASBs to save users from doing dangerous things.
Web app developers could do a lot to help security departments but I suspect they intentionally don't because they perceive that it would harm adoption.
Relatively simple things that SaaS companies could do to make our lives easier include:
* Ability to "claim" email domains to corporate ownership - that is, if any user tries to register with one of our email domains, they are automatically added to the corporate account with appropriate sharing and security controls (to be fair to Trello, I believe they do this - as do Apple, Google, Microsoft and a few others)
* Making OIDC/SAML/SSO a standard option rather than something you have to pay for the super-duper $15k+/month enterprise plan that you can only get after weeks of conversations with sales (if anyone from Twilio happens to read this...)
* Ensuring there is "organisation" support - with security/billing admins that can manage the account, set mandatory 2FA.
* Even just something in the sign up flows where it asks if they're setting up a business account, and if so, asks for their security/IT contact and pops them an email. Most users aren't being intentionally malicious, just they aren't aware we'd like to know (despite repeated communication that they tend to ignore!).
Long term, I think we need better industry-wide solutions to Shadow IT that don't involve invasive proxies. I haven't fully thought through what that would look like, but something like a Do-Not-Track header, but to disable users setting up accounts. Or TXT records on DNS hosts which would cause any attempt to set up an account with that email to automatically fire off to an admin user for approval, etc... See how Google forces mandatory safe-search for schools: https://support.google.com/websearch/answer/186669?hl=en
Unless I become the bad guy, it feels like they are trying to inventory every possible way to leak our GDPR data. And this is how you get micromanaged or fired.
It doesn't help that SaaS companies tend to put the things required for security (OIDC, mandatory 2FA, organisation support, sharing restrictions) on the expensive enterprise plans, which mean that IT need to go back to the user and say if they want to use it, they need budgetary approval for the $15k/month version. This either kills it (and makes them sneakily sign up for the personal one) or means it won't get approved until their departments next quarterly budget meeting.
While I understand that SaaS companies want to find unique areas they can use to upsell enterprise customers, I feel pretty strongly about basic security features being used as that leverage. Especially as there are many SMEs like us that work in a regulatorily complex environment but don't necessarily have the budget for the top tier just to get that security (UK finance, so we have GDPR/ePD/PECR as well as PCI-DSS, MIFID II, POCA, and a bunch of other FCA regulations to comply with).
Ultimately this means we end up saying no to users more than we say yes, which as you say, frustrates them and pushes them into shadow IT. Then we need to deploy proxies/CASB to catch users trying to use shadow IT and blocking sites.
However, when you're talking about something like external hosting and transferring data outside of your organisation, I think there is a line that has to be drawn, partly just as a responsible corporate citizen and partly because of the potential liability when laws and regulations such as those you mentioned attempt to mandate that sort of responsible behaviour.
In an obviously sensitive field like finance, healthcare or law, bypassing the rules and setting up shadow IT really should be a serious disciplinary matter, possibly even a firing offence. It is, after all, potentially causing the company to break the law, not to mention creating severe security and privacy risks, and the damage that can be done by a small group or even a single individual can be catastrophic.
Imagine a hospital or law firm putting sensitive data in Trello boards, for example. Or details about a new product.
But it doesn't have to be either or. These are big enough companies that they should be able to afford the time and resources to design easy-to-use UI that also allows the features power users are looking for. I know some people will say it's not easy - but this is a hard problem because of management and time. If you do enough testing and iterations, you will end up with a good UI. It's just no a priority for a lot of companies.
This is a really compelling sentiment. Do you have any companies you think do this well?
In the early tech days "Just build it first and maintain momentum" was enough to win in market.
Now, with the cost of running a business going lower and lower (lots of infrastructure is automated, business functions can be done by 1 person and software, etc), anyone can compete with you and if they have a better experience, users will go there instead.
So many viable business are being built by companies that punch out a niche in a larger market and designing the perfect experience for that niche.
The availability and quality of collaboration tools have skyrocketed. What Microsoft really wants to do is find ways to force users to use their atrocious enterprise tools that are 20 years out of date in terms of user experience. (I've used Planner, it's free to me as part of Office 365, and I don't see how anyone can call it a Trello clone.)
To me I think it depends what your power user cohort looks like. Are your power users also where you make your money? Are they an important cohort to learn from to innovate to stay ahead of competition? Are they organic advocates for the product spreading the word & building brand value for you?
Which case kind of determines how I would adjust business strategy. If they're revenue drivers, then tailor the UI to them from the get-go. If new users are important to continue growing the power user revenue base, make the new -> expert conversion easy (separate sign-up flow, ways to identify how to get them access to the power tools they need without overwhelming them, etc). This doesn't even have to be UI changes. Could be training materials, courses, hands-on experiments, sandboxes etc to ramp up beginners to where they want to spend revenue.
If they're providing market research to maintain your edge, then maybe some amount of progressive discovery instead (e.g. an advanced drop-down for a given screen to tune the knobs, API to automate, or whatever is relevant for your business). Maybe some good task-oriented documents to help new users ramp up to be power users.
If they're advocates then do what you can to make them happy or excited. Some times holding off on a popular feature can build some excitement about the launch to increase the reach of the announcement to attract more customers. Avoid massive redesigns that break them or build a gradual transition plan (don't pull a Digg). Feature requests are important to listen to but don't necessarily need to be addressed to keep good will (like what Yelp did/does with incentives for power Yelp reviewers). For technical things, giving them a bit of outsized attention to solving bugs that are friction-causing might be warranted to maintain the good will.
For my project, a web-based forum, I categorize UI controls as beginner or advanced, and hide the letter behind a setting.
New users see only the essentials, intermediate users see both extra controls and hints, and expert mode takes the hints away.
I've had overwhelming success with this technique in user studies, both with beginners doing register-comment-vote, and advanced users tasked with "vote against my vote on this item".
The best part is how easy it is to layer the UI like this with HTML and DOM. My concept works in 10-year-old browsers and I believe I can extend suport even further!
https://old.reddit.com/r/dredmorbius/comments/69wk8y/the_tyr...
Most users need only a few features and the UI can be made very simple and easy to learn. However, a small percentage of users need more powerful/hard to use features, and the needs of these users usually determine which product is purchased.
Since it’s advantageous for everyone to use the same product, most corporate employees will be stuck with a hard to learn/use product. Vendors of low-end/easy to use products won’t be successful selling to the corporate market.
What’s different now is that there is a large market for inexpensive easy to use phone apps selling to individuals. You can make a living selling to that market, but you will never be as big as a company that sells an expensive hard to use product to the corporate market.
On the other hand, you lose the marketing war. Articles are written “comparing” your software to competitors, and they completely miss that you have feature X because it wasn’t staring them in the face as a button or a checkbox. Or your software is considered “simplistic” and maybe not “worth” its price or effort, etc. when in reality it may be a powerhouse under the hood.
Pick two.