An open letter to the next CEO of Autodesk

Dear incoming CEO of Autodesk, whomever you may be:

Carl Bass recently announced that he was stepping down as CEO of Autodesk. While he was there, I've talked with him from time to time and he showed me Autodesk's Pier 9 workshop. We haven't always seen eye-to-eye, but I generally like him and think he is a good guy.

Under his tenure, Autodesk developed a program I know and love called «Fusion 360» (F360 from here on). I've been a user since it was an Autodesk Labs project simply called «Fusion». F360 is a very-nearly great modern, multi-platform CAD program. I was first attracted to it because we use MacOS, and didn't want to have to have secondary machines, dual boot, or run Windows in VirtualPC / VMWare Fusion / etc for CAD. That ruled out more or less every serious, professional-level CAD system.

Beyond our platform religion, as a startup, it was also hard to justify spending order of $10k a seat for something like SolidWorks (though we did very seriously consider it, for a time).

Getting started with F360 is amazing compared with just about every other CAD program I've tried. It has such potential for greatness, but maddeningly, it never quite achieves it. It's the hope that its potential will someday be realised that has kept me around, but that has caused a great deal of pain and frustration.

For years, it was plagued by instability. I'm generally a calm person, but found myself screaming on the forums begging for the then incessant crashing to be fixed. At one point, to their credit, Carl's Autodesk sent a QA team to work with me for an afternoon in Burbank — they even bought me an at the time top-of-the-line MacBook Pro (actually, the one I'm writing this on), because they insisted that it was my use of a MacBook Air that was causing my issues.

Amusingly, despite their insistence that the program was stable and that my experiences were anomalous, within minutes of meeting the QA team and playing with their latest build of F360, I was able to crash it on their machine without even trying. Eventually (read: years later), the crashes subsided and the annoyance of wasting hours redoing work that was lost to them became less of an issue.

The reason I bring that now resolved problem up is that it, in the meta, it exemplifies my primary frustrations with F360 — so nearly amazing, but hampered by little things that somehow take forever to fix. Since stability was resolved, my biggest frustration has been scene / assembly 3D navigation. OpenInventor did a better job in the '90s than this modern / user-centric program does today — and, maddeningly, as with the crashes, progress there has been imperceptibly slow.

I believe this stems from and reflects a systematic issue of focus and product management / leadership, and I write you not because I want it shaken up (everyone I've met on the team seems sincere in their interest to make a great product), but because with a bit of direction, you could see its potential realised.

The following are a few suggestions that would help immensely:

First — the Product Manager (one person, not a committee) should have an extremely clear and focused vision. It's great that you listen to people in the Ideastation, but this should be a large funnel for ideas, not a voting-based system for deciding what to do (it's only half that anyway). Many popular ideas correspond to niche things that require a huge amount of development time, but wouldn't move the needle for most users, and many great ideas that are relatively easy to implement no-brainers go with few to no votes because they're not sexy.

Second — new feature development should be frozen periodically (I suggest one quarter per year) and existing features fixed / refined. F360 is filled with great ideas that are implemented to the point where they are demoable, but they fall apart rapidly under real-world use. That, I think, reflects one huge / sweeping issue that should be immediately fixed — testing needs to be done primarily by naive users.

I'm absolutely convinced that the main reason it took so long to fix stability is that the testers had learned through experience what things would trigger crashes, and without thinking they worked around them. When you watch the Technology Evangelists do F360 demos, things look incredibly linear, natural, and complete, but this is because they know where they're going and have practiced and refined getting to a final design.

For real users working on new designs will have many false starts, roll-backs, and a lot of experimentation. Naive users, in particular, will do the most natural things, and when those things don't work, they will be frustrated. Experienced / non-naive testers will avoid those and they and anyone observing them will get a badly misleading picture of how well things work.

Simply by regularly having a large pool of new, naive users testing the app, the development and QA teams will learn much more about where work needs to be done.

Third — I mentioned this before, but please fix scene navigation. If I pinch to zoom into a design on my trackpad, it takes a ludicrous amount of two-finger-pans to get from one corner to another. Orbiting and flying around things is erratic and needlessly difficult. For me now, this is the single biggest / most frustrating waste of time when working on designs — and it doesn't help that I have experienced programs that do it right.

Fourth — kill the timeline and replace it with a dependency graph. This is a huge symptom of non-naive testing. The timeline demos well, and it makes sense if someone is making the same thing they've done a hundred times in 20 minutes, but when you're building a product, it is absurd and unnatural to think that things would be linear, or that tweaking something I worked on a month ago should require me to undo every unrelated thing I've done since then.

Closely related — fix parametrics and build a real symmetry engine. Almost any serious design has replicated features, and can be parameterised. Parametrics have been in F360 for years now yet I have not to this day been able to make them work for any non-trivial design. Like so many things, they seem to have been built up to check a box, add a line to marketing material, demo well, and then left uncompleted.

While parametrics at least exist in demoable form, symmetry and patterning are so poorly built out that they might as well not exist at all. Watch this quick video to see what's possible and imagine how tedious and error-prone doing the same things would be in F360.

Finally, but not least—rip out cloud dependencies and make F360 a complete stand-alone program. It's great that the cloud is there to augment what the program can do, but it's insane and ridiculous that it should be an absolute necessity for the basic function of what is basically just a local program. For something browser based like Onshape, that at least makes sense, but for a native application like F360, that aren't doing real-time collaboration or computational heavy-lifting most of the time (if at all for most users), there is no reasonable technical justification for making cloud backing essential for anything (save for things that actually need network computing like off-machine processing and collaboration).

The cultish insistence by the team that F360 is a cloud program and that it is impossible to make it work well by itself but be greatly enhanced with cloud backing is like arguing with Trump supporters insisting that clear and obvious facts are false. There is a huge contingent in the community that wants or needs this, and there is no rational technical justification not to give it to them.

In general, if you do the above, and closing the circle to complete things rather than leaping to the next cool new feature, the program will almost sell itself. It really has the potential to supplant every other CAD software out there, and it would be awesome to be able to recommend it to people without reservation and caveat, and maybe even to have Apple start using it to design their products on their devices.

Sincerely thanks and good luck,

~ Scott Menor, CEO Roambotics, Inc.

Show your support

Clapping shows how much you appreciated Scott Menor’s story.