Here's the second part of the post I wrote earlier. The original title was ‘Common problems non-technical founders run into’ but in reality, I think these are the problems anyone who is just starting out managing product development process runs into. These were my problems too when I just became a CTO after working for years as a developer. I hope that my thoughts and my experience will help you or somebody you know with their product and save some nerves and time.
Problem #5 Poor communication
That often happens when the team is remote, but I’ve also seen the same thing in the office environment. The founder is expecting his development team to do everything on their own and only shows up once a week for high-level guidance and setting priorities. Unfortunately, developers need constant attention to be effective. That doesn’t mean you have to bother them every hour asking how they are doing, but you need to make them describe their work and break it down into a trackable task list. Developers usually hate that so it’s your job to make them describe their plans and create a list.
Let’s say John is going to build an authentication feature and he’s a frontend developer. This feature consists of several steps — login screen, signup screen, password reset screen, hooking up to the backend and displaying validation errors. Then, of course, writing smoke tests and deploying to the server. That is about seven steps for a week. If you see that it’s Wednesday and your developer is still on step one, then don’t expect the feature done by the end of the week. You need to check daily and ask if you see that there’s a blocker. Developers will try to solve the problems themselves to look professional and maybe you would decide to skip the password reset page altogether for now.
Problem #6 Lack of feedback
There’s a good rule that you need to deploy and test often. I will try to write about this a bit later, but the idea is that in the ideal world you would be able to see and test daily progress on a staging server. Too often founder is too busy to test what developers have done for weeks or even months. Developers are not testers, and they don’t have your vision and your understanding of the market. You need to show up often and test features that have been developed. If you find bugs or unexpected behavior — report them, preferably in a structured and written form, describing the scenario, supplying screenshot or video.
That is something QA engineer, project manager or product manager does. It takes time, it is boring, and it gets more complicated as features build up but it needs to be done by someone other than the developer. Otherwise, you will suddenly realize that your product doesn’t work the way it should work and everybody will be frustrated.
Problem #7 Too much engineering, too little business development
Sometimes it takes months into development without anyone except founder to see the product. I call it founder-driven development, and it’s not something you want. No matter how scary it is, you need early users to use your product and provide feedback. You need that to know what features bring more value. Otherwise, you will be in constant doubt about whether your product is ready for the big launch. And when the big launch happens, there will be no one to applause because really, nobody cares. There are no shortcuts around this. For example, if you start building your product as an internal tool for an existing company you can use employees as early testers. But they won’t be paying for the product, and the real validation happens only after you have a paying customer.
I’m no customer development / sales guru at all, but I know how projects that are driven only by founder vision feel from the developer side. We, developers, can see that the project is going nowhere, especially if it’s been a year of development and there are zero real users and tons of features in the backlog. Best developers will start looking for the job sooner or later because demand is high and they have the choice. And by that time if you haven’t invested in documentation and test that might leave to critical problems.
Problem #8 Expecting your developer to work with you forever
Build the relationships with your team but remember that people will leave eventually no matter how hard you try. Even cofounders leave their startups. That is something any experienced manager will tell you, and this is something you need to prepare for from the very beginning. Your features must be well-defined, but you must own the documents and editing history. You must take care of IP rights transfer. You need to make sure that your dev team constantly commits code to the repository you own. You need to own source files with the designs. You need to make sure that deploy process is documented and there is no special care is necessary for your app to work across server restarts.
The worst thing that can happen is when your main developer leaves. It can be your tech co-founder who got burned out and can’t take it anymore, or it can be the genius freelancer from a third-world country you met on the internets. Because software is a living thing, you will need constant updates and bug fixes, especially if you have users already. Make sure you have a backup plan. I usually recommend having at least two developers on the team so that they can share the knowledge.
I guess that’s it for today, let me know if you have any questions or you want me to write about anything specific. I’ve been managing product development for four years to date and will be happy to share my experience. Would you be interested to read more on the topic? For example, I thought I could write about how to hire your first developer of how to make sure that you partner with the right person as your technical co-founder.
(This post originally was posted on Reddit)
