{3} Tech Stacks, Roadmaps & UX

Knowledge from Arvid Kahl, Matt Wolfe, and Sarah Doody

Chat #1: Arvid Kahl

Calmly building the Bootstrapped Founder in public.

Arvid Kahl:
The best tech stack is the one you already know.

Dane Lyons:
This is usually true. But there have been cases where I've invested time learning a new stack with satisfying results.

- NextJS
- VueJS
- RoR
- jQuery
- Wordpress

Arvid Kahl:
All 5 of these are incredible technological advances. But none of them is such a quantum leap that the products they are used for couldn't also be built with other tools.

That's the idea here.

Dane Lyons:
Right. I could still be building apps with PHP/MySQL and vanilla JS. You can do amazing things with that tech stack.

I didn't include potentially hundreds of examples of technologies I've invested in that weren't worth the effort.

Arvid Kahl:
And even the ones that work come and go. I built great stuff in Angular 1. Or Ember. Or Knockout. And with CoffeeScript. Gulp. Grunt. Yeoman. I'm old.

Conclusion:
Developers should think more about the mileage they get out of their technologies. It's a waste of money to buy a car every year. Likewise, learning a new framework every few months is a waste of time.

---

Chat #2: Matt Wolfe

Creator, Investor, and marketer obsessed with AI, #NoCode, tech, and the creator economy.

Matt Wolfe:
I find it so cool to watch in Google Analytics and see where people are viewing my website from at any given moment.

As a sidenote, FutureTools went from 0 daily active users just 10-days ago to peeking at 2,000 active users today. 🤯

Maybe a case study is in order. :)

Dane Lyons:
Congrats! 🥳

How do you manage the roadmap for FutureTools?

Matt Wolfe:
I literally have a checklist in Evernote that I add to when I get an idea or someone gives me an idea. I'm just working through my checklist.

As far as the tools that get added, I have a whole process for that. I vet everything myself. I'll make a video on what I do soon. :)

Dane Lyons:
Simple tools are often the way to go. I'm always tempted by more collaborative tools such as Upvoty. But in the end, I also usually go with a basic doc.

I'm interested to see how you vet new ideas.

Conclusion:
Don’t over-engineer your process. People tend to worry about a simple process being insufficient at scale, which is probably true. But it’s better to focus your effort on delivering a product than worrying about future problems that are easily addressable.

---

Chat #3: Sarah Doody

I'm the Founder & CEO of careerstrategylab.com where I help high-achieving UX & Product professionals get hired.

Sarah Doody:
UX people need to be both problem solvers and problem spotters.

Dane Lyons:
I agree. UX people need to be problem spotters. Many teams over-rely on users identifying and articulating friction points.

Do you recommend using tools like @fullstory to help spot problems?

Sarah Doody:
Sure that’s a good tool.

But also relying on other people like customer service, marketing, sales, etc.

Dane Lyons:
That's a good point. Insights are a team activity at every level. It's a sign of a good culture if people feel free to collaborate between departments.

Siloing creates bottlenecks.

Conclusion:
The boundaries between the thinkers and the doers should be fuzzy. I don’t believe it’s healthy to have an organization where stakeholders and managers think about the product, identify problems, and assign tasks to contributors to execute blindly.

The people doing the work should be mentally invested in the task at hand and the bigger picture. This can help identify opportunities and points of friction that might otherwise be overlooked.

Sarah also pointed out that the boundaries between departments should also be fuzzy. Marketers should feel free to talk to the product team about UX problems.

---