Our first post on Subs prompted an interesting question (which, if you missed it, you can subscribe for updates here.) How does one person juggle the many parts of a startup? Even those outside of their domain? As a founder with many responsibilities, I try to focus on a few goals to achieve great results. My advice has no basis more reliable than my own meandering experience. I will dispense this advice now.
First: I try to work on problems in as small a scope as possible. My time is precious and working on full-blown solutions (instead of small scoped ideas) would only take up more of it. Just like a tool that does too many things, I try to focus my startup on being the master of just one thing for now.
Second: boring solutions always get the job done faster. That one major feature needs to work before anything else. That feature doesn't need to use the latest and greatest tech.
Third: dogfood your product as soon as possible. Subs is currently serving as my dedicated password manager, so I know exactly what I need to fix next.
Keeping those goals in mind, I use tools I'm already productive with and know well. New tools can be great, but it takes time to learn them. Introducing new tools to my workflow takes time. This gets a little more nuanced when it comes to the various tasks, but if it works, it works. Blame the plumber, not the plunger. Anything you practice, you'll get good at. Right now, I am practicing starting a startup, not learning new tools.
As a developer, I've been using Sublime Text 3 for just about ten years for everything because it's boring and it works. I don't need to worry about anything else, because Sublime just works for me. I want to focus on my code.
For front-end development, I use VueJS and Vuex. I build with Vue CLI. Everything is super fast, performant, boring, and they work. I know how to solve almost any problem I come across. My backend is usually built with Express with Sequelize. Both are very fast and robust libraries. They are also easy for others to pick up and learn. Anything related to authentication and authorization is done with PassportJS, a very solid and well-tested piece of middleware, that's also driving all OAuth2 authentication with Google in this project. Their documentation is short and to the point.
My user experience research is pretty straightforward: I call a friend and ask them to try it out. Later I will add more steps, but I want to get as much user feedback as possible, but only when it's ready. I want to impress people with an awesome product.
If they can, they'll give it a go and provide me with some feedback. I'll fix things up, then call more people, have them try it out, and get their feedback as well. Every single problem these first sets of users have become top-priority for me to fix. Then I rinse and repeat, collecting as much feedback as I can.
While all of this is going on, I try and remember that data points are not trends. Before throwing time and energy at a fix, confirm that one user's problems are others' problems as well. At this stage, you want to fix things that have the largest impact on the overall experience for your user base.
For now, I'll be doing a lot of marketing on Twitter. I'm admittedly not the best at tweeting. If I can find someone to help with writing tweets, I do, but I also make sure that I'm documenting the process of building Subs rather than spitting out memes. Every tweet has to be meaty, which means I have to develop things worth tweeting.
Articles are also a big part of my marketing toolset, so I have someone helping me. We have a call or a video chat to talk about article ideas. They write down some notes and start working on an outline and drafts. We'll meet regularly to go over the drafts together to check for tone and make some changes, and I'll approve of a final draft that gets posted online. This saves me a ton of time and keeps my tone in articles.
Ultimately, when it comes to marketing, I'll do anything that saves time. My goals are to build a very solid version of the product, get it into people's hands, and get feedback. The less I need to worry about drafting and copy editing, the more time I can spend writing excellent code. Which, I think, is something to write about.
Selling your idea sometimes means ignoring anything that might distract you from getting it out of the door. Even when you're getting started, you might hear suggestions and requests from big companies, if you are lucky. The best thing you can do is to save these requests and ignore them for now. Give the big company a platform to give you feedback so that you have everything saved for later.
Create an issue tracker (like GitLab issues) where everyone can submit feature requests. That way, you can interact with your user base and they'll know their voice is heard, which is what you want! Don't let it distract from your goal of releasing version 1.0, and don't be intimidated by big companies. It's valuable feedback, but as a founder and wearer of many hats, you have limited bandwidth. Your focus should be on the smallest scope possible, on what gets your product built and working.
Building a product on my own is hard work, so something positive I work towards is creating opportunities for others. I enjoy offering people the chance to learn the way I learned. I try to give newer developers the chance to help me out if it helps them out. Letting a junior dev watch you build your product and ask questions, assuming the right non-disclosure agreements are in place, is a great way to keep me accountable and for them to learn.
I'm sure by now you can sense a theme running through the way I work. The latest and greatest in languages, platforms, and frameworks are always exciting, but not when it comes to getting things done. I need to be able to work quickly to gets Subs to you, and that means boring and reliable methods. If you want to see the proof and stay updated, sign up for updates at https://subshq.launchrock.com.