Thread by @joshuamschultz

Matt is hitting the nail in the head here.

While growing a fastener distributor biz, I learned to code, built a custom ERP, learned machine learning, all while applying it to my business(s).

The combo is 100x

https://twitter.com/LongvueMatt/status/1344627119083687941

Some of the past assumptions on how to run a biz melt away when you understand the tools out there, and can build anything you want.

But

Just because it’s cool, will automate, or can be built doesn’t mean it should. Many tech assumptions melt away too.

Here is a few things I learned while building niche vertical tech software for a few different industries...

1. Not everything needs to be built in house.

If it’s an extremely common problem, it’s better to have an outside software firms product that is professionally managed.

Less cost, less maintenance, more diverse feature input from users.

2. Not everything needs to be coded.

There are powerful no-code tools that can 10x dev time while keeping common code errors and breakages to near 0.

Low cost, low dev time, low maintenance.

3. There are 100s of things you could build, but many that you shouldn’t.

Prioritize wisely.

Consider:
1. Cost
2. Bottomline impact
3. Customer impact
4. Strategic alignment

Weight these, rank ideas, work on what matters most.

4. Building has whats known as technical debt.

Get a basic lay of the land first.

If software will be data analysis heavy, but you start building in rails because dev speed. It will take more and more work to do simple things.

Take the right path, avoid tech debt

5. If you find an area where the wheel doesn’t seem to have been invented yet, consider in-house development.

This can be easier and less costly than you first think.

This can be an additional revenue stream, and if done right, a cash cow to feed growth in the rest of your biz.

6. When designing tools for SMB, one of the most important barriers to use is what I call intrusion.

How much will using this disrupt the current day of users?

Products for these industries must be less optimal in performer to be more optimal intrusion-less interaction.

7. Adoption in small business is all about the initial wow.

Design an example to show the worker the power of the software in less than 15 seconds.

Yeah, that’s right.

Adoption will sky rocket.

8. Designing software for SMB quickly requires an understanding of multiple fields before you can do it (without a lot of relationship frustration, and rework). A few are (regardless of application):

1. Systems thinking
2. Ownership perspective
3. Cash cycle

Cont.

4. Financial statements
5. Management and people problems

And then the companies specific sales cycle and operations cycle.

9. Depending on the size of the company, the problem the payor (owner / exec) thinks needs solving is different from the actual problem that needs solving.

Talk to people from the bottom up to really understand the issue.

10. Desire Levels

Owners usually want data
Managers want control
Laborers want automation, simplicity, and intuition.

Design all three into your product for a winning solution.

Dashboards/emails, control and assign, well thought out UI

11. SMBs use lots of software, and this system doubles in useful less if it can receive and talk to other software.

BUILD EVERYTHING WITH AN API AND WITH DOWNLOAD/UPLOAD CAPABILITY

12. Don’t over engineer solutions.

If what you want are KPIs, don’t build and entire suite of software, build a data pipeline to grab data and push to Dash or PowerBI.

Over engineering has too many outfalls to talk about here.

13. Don’t let the words AI and Machine Learning scare you. It glorified statistics. And when you stack statistical models on too of each other, you get machine learning.

You can use these models to
1. Predict
2. Classify
3. Segment
4. Decide
5. Check
6. Read/write

Cont...

7. Cluster

If these verbs are part of something you are doing, it can be automated or augmented (use computer to help human rather than do for them).

14. Anything you do in excel more than once a tear can and should be automated.

Last week I was shown a series of 20 spreadsheets that are combined / manipulated once a week. Takes 4 hours.

I gave them a script. 20 seconds, <40 lines of code.

These tools are powerful

15. If hiring, prioritize SMB ops experience over CS degree.

Much of CS degree is theory, great for the edges of software dev doing novel things (Netflix, Tesla, etc). But they lack basic practical experience.

I’ve taught most of my CS basic coding best practices, which is sad

Cont...

You also want someone who gets most of the big picture as they build so they don’t do things like have PO entry and adding individual lines to that PO on different screens and parts of the program.

In summary

I’ve owned and ran 4 small businesses in total, and have built software for all of them, along with a lot of nocode and small automations too.

I LOVE talking this stuff, helping, and even occasionally building.

Let me know if I can help!! DM me.