I’ve read a post on reddit recently and decided to write about common problems non-technical founders typically run into and what are the ways to avoid them. I am a developer with about 18 years of experience and worked on a lot of projects and started a few myself so I believe I can see the picture from both sides.
Problem #1. Lack of documentation on features
Support documentation is essential. For some reason there’s a belief that you can point your finger on a mockup and developer will figure it all out himself. Maybe he will, but if you would provide even some little description of how things should work and why you want a specific feature will help a lot. There’s no need to spend months creating those docs, but creating a google doc describing the feature and keeping the discussion there will help you a lot throughout the project. Developers will change, and after some time nobody will know why this or that was added and you will have a hard time onboarding new members to the team. Of course, if you are doing quick and dirty MVP, you will think you don’t need all that. But then someone like me will have to rewrite your MVP from scratch to make it maintainable.
Problem #2. Lack of designs
Developers are poor designers typically. Again, for quick and dirty MVP you might get away with a bootstrap theme, but soon enough you will want to add things that don’t have pre-made elements, and you will ask your developer to create something. It might work out well if your developer has graphic design skills, but design muscle has to be constantly used to be able to work well. I have a graphics design degree, but after being a developer for so long, I would instead ask a designer to create a mockup for me. That’s what I do actually, I usually team up with a fellow designer and pay them from my pocket. The result is usually beyond expectation, and I haven’t had a single client who didn’t want to work with a designer after that. You don’t have to hire a full-time designer, keep someone part-time to do quick mockups for you.
Problem #3. Feature creep
That usually happens when you hire an inexperienced or shy developer or agency who never tells you that you are asking too much. I would say it’s a developer’s responsibility to manage the client, but you as a non-tech founder should also be aware of this problem. Feature creep usually happens when you expect your project or milestone to be done on specific deadline, but then you start changing or updating (refining) the requirements. It happens all the time on every project I worked with, especially on those where there’s no feature documentation (Problem #1). That leads to missed deadlines, frustrated developers, client losing money and potentially can kill the project.
You need to understand that every estimate or expectation you have becomes obsolete when requirements are changed or updated. Your goal is to do as much as possible within time and budget available, not fit in as much as possible details and make developers do it for you anyway. So try to define what you want in the very beginning. Create a roadmap and then create a plan for the next 1-2 weeks. Make sure to update the roadmap after each passed week because as the project goes you learn more about the requirements and implementation, number of requirements grow and time available shrinks so you have to prioritize. That is typically why you want a project manager.
Problem #4 Treating time estimates as a rock-solid commitment
Related to problems #1 and #3 and multiplied by #3. As the project goes both you and developer learn new details about it, it’s just how software development works. It’s more like an experience of the stone carver who frees up his sculpture from stone vs. construction of a building. It doesn’t mean you can’t manage the process, but developer usually gives you an estimate before doing his work and actual work can take 3x more time based on actual circumstances he will uncover during the process.
If your features are not described well, and there are no mockups, there will be a much higher level of uncertainty, and it will make estimates even more unreliable. You need to constantly communicate with a developer to understand what kind of roadblocks or questions she has. Sometimes they will make a decision for themselves, and it might be a wrong decision. Sometimes she will spend days on a problem that can be avoided by doing feature in other, much more simplistic way. That is also a job of a project manager.
There are other problems that are just on top of my mind and I'll make sure to write them in the near future:
- Poor communication
- Lack of feedback
- Too much engineering, too little business development
- Being too cheap and expecting developers to set up servers and react to incidents
- Expecting your developer to work with you forever
(This post was originally posted on reddit)
