What Tech Do I Use?
This week’s topic is all about tech. However, you can apply these principles to what you do for product development of service as well.
The problem is, how do I make my product or service? I’ve done all the steps, and I’m convinced I need to try and build this thing. But how do I do it?
There are more tools available to a maker than ever before. With code, each language has several different options for how to build the thing you are passionate about. And, despite what you may have heard, the latest and greatest may not be the right choice! I want to bring some ideas to your attention so that you can be thinking wisely about what you want to build.
Own Your Product, Not The Method
You have to understand that developers and designers and craftspeople want to solve problems. There is a deep seated sense of curiosity that burns in those that are worth working with. That’s how they got to where they are. A relentless pursuit of learning and new efficiencies, style, innovation, and fun!
You have to keep this in mind when you are looking at picking up a technical approach. If you are excited about what you want to build, own the product, not the method. Do you care if it’s Ruby on Rails, PHP, or Python? Do you care if it’s Javascript or if it’s punch cards? Probably not. If you are going to use experts to build what you want to build, let them be experts. You will have enough to do without the nuances of deciding on code libraries.
Now, there is one exception to this.
Do NOT use the latest and greatest
It all boils down to this. If it doesn’t work, it doesn’t work. If the latest and greatest technology does all kinds of things but leaves gaps in the user experience, don’t do it. Here’s a classic example.
A user needs to probably register to use your online product. This functionality requires a system that will allow a user to create an account, securely access the service, self-manage their credentials and own things in a database. There are great, promising technologies that make this very difficult to do because they are focusing on specific problems first. If a major piece of the experience is missing, don’t use it. Something that works is more important than the latest and greatest tech no matter how cool it is.
Ship as soon as it works
You will want to create an ideal experience and then build towards it. First, make sure it works. Then make it into whatever the next fancy iteration is. If I can use your service and not have any bugs from the start, then things get better over time, you are creating an expectation of constant improvement. You are listening and responding to what users are saying.
This is so important. You have to get what you are building into the user’s hands as soon as possible. Your ideal experience may not be theirs. In fact, you may not even be able to dream of what your users are going to want. So get to something that works first. Then polish it as you go, responding to feedback from customers.
Accept Limitations As a Creative Catalyst
One of the biggest fallacies of the creative world is that a blank canvas is a great place to start. That is completely wrong. If everything is possible, then everything is possible. Where/how do you start? When do you know you are finished?
I create limitations that may seem arbitrary, but they force me to deal with ideas in creative ways and come up with solutions faster and in a more creative fashion. If anything truly is possible, create limitations on time or budget. How can I do this for free? How can I build this in 2 months? What if I had to launch in a month?
One great benefit of this is that you will quickly see why you want a mature platform and team to help you. If you want to build in two months than you can’t be futzing around with a platform that doesn’t have security completely figured out yet.
Here are a couple more things to keep in mind:
- Use a platform that is at least at version 1.5. It seems that most tech platforms seem to figure out some big problems by then.
- What are the pros using? If a large company like Google or Apple is using it, it’s safe to assume that you will be in good company.
- How much support does it have? Go to StackOverflow and see how many posts are in a tag. For instance, Django currently (8/2017) has 150,997 posts. That’s a lot and based on the conversations; you can see that support is abundantly available.
- Is it decoupled? This means you can change out parts of it with little or no effect on the rest of the system. Need a new database? No problem. Need a new front end, sure, just change the templates. If you are using a proprietary system that ties it all together, you are locked in, and that is a dangerous place to be.
Once you commit, commit fully
One of the most time sucking activities is reanalyzing what you are doing every step of the way. Should you be aware of other things in your industry? Of course, but don’t re-evaluate every decision weekly. Once you commit to a technical solution, commit fully and make your solution happen.
Join the Conversation
This is the from the archive of an ongoing series called Making Things That Matter. Each week I will send you an email with another step in the process of building products and launching ideas. Signup here to join the conversation.
