> 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.
>But the number of your customers who want unbounded complexity is very, very low.
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!)
> Users don't want complexity, but they do want flexibility
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.)
Yep, and pandering to the lowest common denominator means that complex things are probably impossible.
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.
I think the ideal is when programs are accessible to novices but at the same time provide instruction to those who care to pay attention and hone their skills. For instance, in Excel, when a user uses their mouse to highlight some cells and create a formula, the formula they created with their mouse is shown in the formula entry form, demonstrating to the user how they might have accomplished the same using their keyboard. This introduces users to 'power user' workflows or tools, while not imposing complexity on the users who aren't interested in learning [at that moment.]
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...
> 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.
Lotus probably had 500k users and Excel probably has 500m.
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.
I am the biggest fan of Unix commandline tools but I think you vastly overestimate how universal unix pipes are. For example, if I asked you to guess (no reading man pages or trying commands out!) how `find(1)` interprets input supplied to `stdin`, what would your guess be?
Comparing your guess with what you learn from the man pages is an indication of how inconsistent most of the classic Unix tools are.
> how `find(1)` interprets input supplied to `stdin`, what would your guess be?
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 :)
There is a tipping point where my flexibility becomes your complexity. As you say, it’s hard to get right. It’s also hard to know when you got it wrong, since customers overwhelmed by the complexity will choose another product, while power-users clamor for more “flexibility.”
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.
Spreadsheets are some of the most complex applications I can think of that average computer users are probably familiar with. I don't know if that's a great example.
The holy grail of design is to get both. Many people draw a straight line with complex solutions on the one side and simple solutions on the other side. Depending on what they are aiming for they choose a spot somewhere on the line.
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.
>I didn’t fully understand this as a developer, but it become crystal clear as a product manager.
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.
> 20 years, I still dont understand how most developers dont understand.
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.
I've worn both product and developer hats, and honestly the way I see it is: You need to decide whether you are building tools or toys. Neither is bad, but you should decide on one and stick to it for the product. You can make money building tools and you can make money building toys. But you're going to turn away customers if you first make a tool, then turn it into a toy in the name of "simplify" and "making it sleek".
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.
You took this in a slightly different direction than I expected, after I was in violent agreement with the beginning of your post.
> 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.
I can guarantee that most teachers do not want "power user" software. I think you are over estimating the need and desire of non tech related professions to use complex technology, unless that complexity is hidden completely for the user and they can take advantage with simple interactions
I think that many people enjoy learning. But they enjoy learning different things. Developer might enjoy learning new programming language. Artist might enjoy learning new painting techniques or may be new Photoshop features. But if you will ask artist to learn Lisp to write image processing algorithm, probably that won't be interesting for him. And if you will ask developer to learn Photoshop to add shadows to that icon, probably he won't be happy either, unless he happened to like both programming and painting at the same time.
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...
Thanks, very interesting! Seems to have fairly high variability across regions (94% in Japan), would be interesting to see a split between industries as well.
I think this depends on the culture of the company. In sale&marketing-centric companies, it can be as you described. In engineering-centric companies, engineers sometimes create features and products that customers haven't asked for, and then it's up to sales&marketing to drive adoption, even if it is against customer protests, because the investment needs to be recouped.
I had had the exact same reaction. My career sometimes feels like a series of meetings in which I implore product managers to keep things simple and consistent instead of adding every bell and/or whistle imaginable.
Developers are rewarded for features, PMs are rewarded for happy customers. It’s usually that simple. Especially in companies where you are rewarded with promotions and bonuses this value proposition rules the entire product. See for example Google’s entire product portfolio.
>Developers are rewarded for features, PMs are rewarded for happy customers.
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.
I think most developers already have the mindset before working in any company. Maybe the mindset propels them towards computers and software development.
You think? When I do hobby work, the reward is getting to spend as much time as I want tweaking things to be a nice as I want them to be. Which is why I've never made anything, but have had lots of fun and learned a lot.
Depends on the dev. I fully understand. But then I'm a minimalist by nature so maybe that has something to do with it. The more knobs and dials there are, not only the more chance for something to break, but more chance for an inconsistent user experience. The latter drives me nuts usually more than the former.
As a developer, if someone does not constantly want new features, I am out of a job. Frankly I am better off with aggressive development even if it hurts customer acquisition.
There is always more engineering work. The questions is does the app need to add new vocabulary type features to get there, or is the work focused on making the API more flexible for 3rd parties, or the signup process less onerous, or making exports take half the time they normally take. There's definitely a balance but they have to be seen as worthwhile and valuable goals instead of adding new words to the object model or new pages to the site. Typical product creation can sometimes be "can I make this thing possible?" instead of "should I make this thing possible or accept that this is not the job of this application". Of course you can make your app do anything you could possibly want... what should it do?
I am so sick of this "shit on your power users" mentality.
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".
Power users didn't build any empires, get over yourself. It's the users you call stupid who do. Also a piece of software and its ecosystem is hardly an "empire"
It's not about shitting on your power users, it's about making your software usable for everyone.
"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.
We hear a lot about keeping products (esp interfaces) “simple”, and rejecting “feature explosion”... but all that seems to fly in the face of the success & ubiquity of the spreadsheet. I don’t understand why this glaring mismatch is not addressed explicitly, more often.
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”)?
The way I look at it: Excel has near-infinite space for the user to grow. Almost all its advanced features are easily discoverable, but they don't interfere with basic work. People get to learn Excel as much as they need or like, and the more they know, the more kinds of work they can do with it.
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.
Nicely put. What’s particularly aggravating is the push to unbundle features from a flexible power-tool like a spreadsheet, into siloed apps which can only do one thing, and charge recurring fees. When a user’s needs morph or expand, they hit a wall and are now held hostage by the service provider.
But the number of your customers who want unbounded complexity is very, very low.
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.
People used iTunes despite its terrible performance on Windows so they could sync their iPod and buy music on the iTunes music store.
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.
Although I agree in principle, I don't quite agree in the specific case of Trello. I think that their intentionally constrained approach to adding features is losing them quite a lot more than 1% of users.
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.
It's funny that a sharable list is such a hotly contested piece of space in the software world.
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.
> 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.
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.
Not infinite-infinite, just with no obvious limit. If task depth was maxed out at 256 levels, I probably would never notice.
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.
>with a DAG, nesting stops being a first-class concept
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.
Yes and no. A DAG eliminates nesting as a concept, but you can, and probably[0] should, still reintroduce it. There is a meaningful difference between tasks that are conceptual subcomponents of another, vs. tasks that merely depend on another. This could be reflected by different labels/colors of DAG edges (e.g. :depends-on vs. :component-of), and could be appropriately visualized in GUI.
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.
Wish I had time to do it. The fundamentals aren't really that hard - a dependency DAG of Tasks. Tasks store metadata, including incomplete/relative start/end estimates I mentioned. You could display it as a DAG, or in a traditional "tree structured task" form by just starting at a Task and walking in one direction to fill a tree, and in the other to fill "backlinks". Add a GANTT and PERT chart and that's it.
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.
I really like this idea. I’m going to take a crack at a simple PoC around the data flow and basic UI this long weekend. I’ll chuck it up on my GitHub; I really enjoy working with DAGs (I’m currently building a dynamic form system where groups of form fields are arranged as a DAG to allow for seriously powerful structured data collection and intra-group visibility/validation rules infinitely nested at work)
Trello is of a certain vintage. It was a breath of fresh air when launched as it opened up new possibilities from the traditional office tools like docs & spreadsheets. But it's still a purpose-built tool that has a really tight coupling of interface-data, so it's not really a part of the next gen of tools like Airtable or Notion that are data-first and are way more flexible.
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.
Having an API really does create an enormous amount of work for you.
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.
> Having an API really does create an enormous amount of work for you.
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?
Formulas are foundational and arguably the reason spreadsheet software exists in the first place (automating calculations), everything else in a spreadsheet application is arguably entirely an attempt to make formulas easier to work with.
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.
In fun serendipity this came up in another HN thread today and someone who isn't me better summed up how formulas were the root product of VisiCalc and the rest of the spreadsheet the implementation: https://news.ycombinator.com/item?id=24664949
You can make products that cater to hobbyists and tinkerers but are still useful for normal people.
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.
> 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.
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 ;)
One of the hard truths about dealing with customers is that they don't care whose fault it is. They're just angry and they want a resolution.
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.
We use Jira at work for bug tracking. Like many useful tools, it was initially sort of snuck in the back door by the development team. It was just a tool for bug tracking. Eventually corp IT took it over and added every possible feature and hundreds of custom fields (90% of which are never used) and it's become slow and bloated. An it's partly on Atlassian for catering to so many whims.
This is probably part of the reason why Apple's UX has been so good (historically, let's not get into a discussion about now) – they aren't pandering to power users mostly, they are designing very coherent experiences for most users. Power user features can reduce that coherence, making it more difficult for everyone else.
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.
Just keep in mind that early in a product's lifecycle, it is those Power Users that are the cheerleaders for your product (driving adoption), and sophisticated enough to offer (potentially) valuable feedback.
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).
Very much this. The only reason I use Apple computers today is because I need access to their walled garden of apps (Safari, IOS) and (now slipping) legacy of workhorse hardware. In the past Macs were great for commercial graphics and other niches.
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.
It's not necessarily power users, it's Steve Blank's earlyvangelists. I don't think it's obvious those two overlap 100%.
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.)
I'd argue that coherent experience vs "power user" features is a false dichotomy. They are at odds, but you can design a program to have a coherent user experience as long as you stick to a subset of features, and hide the incoherent features away from the coherent interface. That's rather abstract, so let me give a concrete example:
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.
My team recently moved from Trello to Jira, and I really miss the simplicity and speed of Trello. Sure, Jira has every tool and feature you could ever think of, but it's so bloated and slow I find myself spending half the time waiting for the UI to catch up to me.
I like it when products have lots of features and customization, but it can't come at the expense of usability
Uh, sorry to hear about the migration - it's understandable given the (over-)simplicity of Trello, but Jira seems like a jump to another end of the spectrum. We migrated away from Jira (Cloud) to Quire which has been amazing. The poor UX and performance were just making it a choire to keep the boards updated...There was famously a reply in a thread (on their forum) about performance issues in which team member replied that they don't understand what the complaints are about as most of their response times are "3 seconds or less" :)
https://community.atlassian.com/t5/Confluence-questions/Jira...
Sorry for off-topic, but is anyone similarly aggravated by some of the MacOS behaviors? Switching between apps with `command` + `tab` will focus but not maximize a minimized application! When you have Zoom in full screen and switch back to it via keyboard shortcut it will not show the window! Every day I experience pain using MacOS and it baffles me this UX persists for years!
How can Atlassian LOSE money on this level of revenues, in this market, with the combination of their tools and shifts in usage... after this long?
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.
They are taking hits and trying to pivot by forcing users to cloud as much as they can. They have first class tools for many parts of the dev lifecycle (their CI server is crappy) and soon they’ll make cloud saas versions of them cheaper so they can control your org’s dev cycle. It’s a slow strategy but i can’t see it not working
> "Another downside," our source added, "is that some clients block Trello which can be really disappointing after you've just built a big board together."
Some industries have regulations that require specific controls, audit logs, and security for any of their data. When employees use uncontrolled 3rd-party tools, they’re inevitably putting some of that controlled data into uncontrolled systems. This can open the company up to massive fines or leave them vulnerable in the case of legal action, so they go ahead and block unapproved project management sites, communication tools, and so on.
Never work in a heavily regulated industry if this type of thing bothers you, because it exists at every level of those companies.
The part that bothers me the most about this is that our app has all of the certifications and controls that they would need - they just don't know that. Soc2/3, ISOs, Fedramp, etc (trello.com/security). But as you point out, you have to get it approved and that requires navigating a lot of internal roadblocks.
I think you misunderstand the roadblock. Especially for any higher security like FedRAMP it is up to the FedRAMP certified holder to vet and have a very solid understanding of that remote service or system they are using at a moderate to deep level. Most sec people will do enough research to know if the service provider are at least an immediate no or not, but even if they are same-or-better FedRAMP level you still need to document them in your SSP (a system security plan for your whole org from HR to Engineering). This also doesn't prevent the situation that you then need to do a deep dive with this other organization to find out how FedRAMP their FedRAMP program like this, because more often than not organizations hide a lot of skeletons on what features/services are actually FedRAMP and what are features they intend to have FedRAMP 6-10 months from now.
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).
We have blocked Trello accounts in our org, mainly because SSO and enforced 2FA was locked behind Trello Enterprise. The department that wanted to use it couldn't get budget approval for that plan, which leaves no alternative but to block it.
(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.
It's the other way around. You only need to buy Atlassian Access to get the SSO + enforced 2FA for your Trello (and also any other Atlassian product) users.
Trello Enterprise (optionally) would secure your content (i.e. attachment restrictions, power-up restrictions, token restrictions, audit logs, team management).
I'm sorry it's confusing. It's trying to say that SAML SSO is provided via Atlassian Access - but you don't need to buy Enterprise to buy Atlassian Access - it's a totally separate product (and does not require Enterprise). We are in transition right now (formerly SSO was provided by Enterprise) and so our final pricing page isn't quite where it needs to be.
It’s not just about having the right certifications and controls. Any approved app has to be worked into the system, included in audits, reviewed periodically, and so on.
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.
Trello is fantastic on the personal end, would love to have an AWS GovCloud offering. So many projects tired of using over-complicated JIRA and Github/Gitlab Issues are not enough... Alas we are stuck using Wekan as a shoddy drop-in for now.
We were significantly more productive with Trello as our project management tool (and this was way before, when checklists were a major new feature) than anything since. We’ve tried all the major ones.
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.
My experience at large companies is that you have some team who is responsible for securely using third-party software. Making sure that it actually authenticates right so that only employees can see it, that sort of thing. This team doesn’t want to support literally every SaaS application in the world, so they try to choose one supported application per category. Pick either Dropbox or Box, don’t use both of them. Etc.
But... "after you've just built a big board together."
"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.
Maybe security? Bigger Companies don't trust external tools much and prefer to hold their data inhouse. But this reads a bit out of context to me. There might be something more to it.
Speaking as someone involved in this, Shadow IT is a nightmare.
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.
In my experience users generally do this when their computers are locked down and IT departments are not responsive enough to meet their needs in a timely fashion. It's a paradoxical case of more restrictions making things less secure.
Unfortunately user expectations tend to be that they want the account set up immediately, and anything beyond that and someone will try and circumvent it.
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.
Under some circumstances, I sympathise a lot with users who are trying to do their jobs, identify a tool that will help them to do their jobs, and then get told "no" by IT, particularly if IT is being obstructive for no apparent reason except throwing its weight around.
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.
Yup. And then IT departments will use users doing it as an excuse for further lockdowns, you can't trust those users after all, look what they do. Vicious circle of mistrust.
I have only two employees and it’s already a nightmare. Notes-taking apps outside of our intranet, people mixing their Facebook cookies with their work (I specifically say they must have two separate Chrome profiles during onboarding), infinite number of Chrome extensions which means any extension can harvest their passwords to any site...
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.
On-prem does tend to have fewer GDPR/security concerns, but a SaaS is fine provided it is adequately controlled, and usually quicker to set up and lower maintenance cost.
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
Mature SAAS applications over focus currently on new releases, features and engineering. I say this because product development resources should be allocated to creating recipes, templates, documentation and communities enabling power and novice users to add complex functionality quickly.
Will Trello ever get to the point where it's declared as complete and development switches to maintenance mode? It seems like this industry likes to develop products until they are bloated messes and then some lean competitor with a fresh look sets up shop and starts the cycle all over again.
I mean... if you have to make the decision between a bloated ui and a simple one that does something well, then the latter would be the better choice. Especially in a market like this where power users could spin up their scripts that they can really customize.
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.
As a UX designer, I see this a lot. Design has come a long way in being valued but very few companies realize how absolutely critical UX is once you have a crowded market.
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.
> 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
This is a really compelling sentiment. Do you have any companies you think do this well?
> With the "total addressable market of people using collaboration tools," having "skyrocketed," according to Pryor ("it just kind of exploded," he laughed), it's not surprising to see Microsoft (and others) looking to roll their tanks onto Trello's lawns.
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.)
Interesting. I would have thought the intersection between power users and paying users would be very high and they would be worth pandering too if their requirements where general enough to applicable to other power/paying users.
I still am holding out hope for progressive complexity to be adopted by the UI & product worlds across the verticals, but anything meaningful here needs to be something engineering can solve across problem domains. I don't know if that's actually possible. The ideal system could support more power user use cases without increased technical maintenance burden/UI complexity & designer burden on a per-feature basis/& product clarity. That seems like a tall order.
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.
Thank you for writing, progressive complexity is a great term.
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!
This is a perennial issue in software design and business, something I struggled with in the 1980s, and I don’t think it was a new problem then.
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.
I sort of feel like the right way to go is build tools that can feed into each other in ways that let users who DO want to go crazy to build their own workflows, instead of creating a single tool that tries to do everything. Basically the Unix philosophy where you pipe everything into everything else.
Or for another perspective, AppleScript, or Android's intents; it's not even that you need pipes, but you need applications that surface enough API for you to extend them. I mean, yes, pipes are a very good option, I just want to point out that the exact form is less important than having something you can hook into.
From a technical point of view, it is certainly cleaner to hide some advanced features (e.g. instead of cluttering up a GUI, perhaps they can only be enabled by lower-level commands). It may even be easier (as expanding a GUI requires more code, more thought for proper placement/layout etc.; and from a testing point of view it is easier to test lower-level commands than GUIs).
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.
On the opposite side, what about making tools that cater only to power users? Tools like Roam Research or Superhuman that are popping up in the productivity space for example. You could just deny customers who are more casual, as you're not going to convert them anyway unless they learn your tool.
Comments like these explain why I stopped using a Trello a long time ago. It just doesn’t do enough to justify using it regularly because you find yourself running up against the same deficiencies time and time again.
Notion does a great job balancing the two. There is immense power hidden behind the slash commands. For everyone else, it's just a great note taking tool.
Pandering to power users and then selling big to a company that does everything it can to undermine and overcharge power users sounds like pretty iconic late-stage tech capitalism to me.
> 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.