Hacker News Reader

Comment by PragmaticPulp | Hacker News Reader

The comment about power users:

> 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.

View on HN

>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!)

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.”

I feel like UNIX tools do this very well.

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 :)

> 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.

> 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.

I think you should strive for what your customer base wants, if the lowest common denominator is 90% of users, then that should be priority

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...

Came here to say this.

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...

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.

And hence why lots of startups failed.

In my experience, its usually project managers and sales doing feature driven development while developers beg them to stop.

Devs have to deal with all the bugs and messy codebase

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.

It’s promotion-driven-development.

I think most developers already have the mindset before working in any company. Maybe the mindset propels them towards computers and software development.

If you are developing stuff as a hobby, new features are still the reward.

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.

>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.

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?

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.

> 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.

Trello is what it is. You can pay lots of money for JIRA or something.

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.

Learning has a cost and most people don't enjoy learning.

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...

Some people? Most people. Statistics put the number of people who hate their jobs at around 80-85%.

Citation?

https://news.gallup.com/opinion/chairman/212045/world-broken...

Remember, as someone on this forum, you're on Over Achiever Central.

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 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

"powerful" is not a synonym for "complex"

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

Whilst I have some sympathy with your stance I feel some of the nuance and complexity might be being lost.

It is, but not on this side.

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.

(Excuse the rant.)

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.

Amen

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.

Seems like one of the better ideas I have seen for a startup.

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)

Glad you like it! I'd love to see what you cook up. I'm noting down to check your GitHub in a few days.

What do you mean by infinite nesting here? Provided, the tasks are modelled using DAG.

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.

We've got some stuff up our sleeves...

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?

Great. And now you have to refactor the API. Your life is suddenly 1000x more complicated.

In our case it's a 30 year old CAD application written in C++, so no

The prime example of that is the Azure Portal. I am an occasional user for simple things. And the portal looks like a B747 cockpit to me

AWS is like 787 and A380 and C-130 welded together.

> 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

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...

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 ;)

> power users who think they know more than they do, who end up destroying their data through the API

That's their own fault IMO. Power users by virtue of their name shouldn't need babysitting.

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.

It doesn't really matter whose fault it is, it's still your business.

And you probably keep better backups than they do. I've had this happen plenty of times. Free backup restore test.

Doesn't matter if it's their fault. If their monthly recurring revenue is high enough, they'll make it your problem. I've seen it happen.

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.

The problem is when 99% of our revenue comes from that 1%

Reply on news.ycombinator.com