Some recent startup advice I got: work on A problems instead of B problems.
B problems are "nice to haves." Their things that you know you'll get done, because they are familiar, and not that hard to check off or check off.
As I began working on healthcare interoperability tools, when things got tough, I began to gravitate towards these kinds of problems. Soon recognizing this as procrastination in disguise, I realized that a good rule-of-thumb for working on startup problems is that if you're faced with working on two things, working on the one that's harder might be the better idea.
This is useful for a couple of reasons:
- Something that's easy is not easy to defend
- If it was easy and produced a ton of value, odds are it's either easy to copy, or has been done before
- Working on hard things is hard to copy
Good management happens away from the "open a pull request" (good managers and operators act as editors, so slack + the comments section is where lots of valuable stuff tends to happen). And, good things take hard work and a while to ship. Tracking the "hard to measure" things then becomes really important. Celebrate wins away from the terminal.
So, try and work on hard things if you're able to. Being good at gauging how long those hard things will take, and communicating that to your team, is also really important.