Managers without a technical background often think that the main thing is to write detailed terms of reference for developers, and after that, all that is left is to ask them to meet deadlines strictly. Yes, this is important.
In addition to the description of functionality, the terms of reference must include the mock-ups of screens with a fully finished design and texts of all the messages shown to the user because it is a bad idea to leave the design and copywrite to software development.
But worst of all, after discussing functionality with the developers, to stand back and wait quietly for the result. Software development is a continuous process, and you need to clearly understand what you are working on at the moment and what there is left to do. The deeper you get into the process, the more likely it is that you will notice when something goes wrong.
Focus on the Main Functions
How can this kind of immersion help? One of the most common causes of deadline slippage is unexpected difficulties in implementing small and not-so-important features. Good developers strive to make good products, which means implementing all the specified elements in the spec. As a product ideologist, you can and should drop all minor features from the plan if they start to take too much time, i.e., more than a few days.
Do not Add New Tasks During Software Development
Once you immerse yourself in the development process and get a chance to see intermediate results, you will have a strong desire to add and change functionality on the fly. Don’t ever do that! Adding and modifying requirements live is the biggest drag on the development timeline; partially implemented functionality is much harder to change.
In 95% of cases, it is better to stay within the original plan and test a new feature conceived on live users. And then make changes based on the feedback.
Control the Developers’ Efforts
Over time, you will estimate how long a task takes, and it will be more accurate than the software development team‘s results. For example, new features are added relatively quickly, while redesigning old features when converting existing user data is always slow and excruciating. Learning to present more or less realistic deadlines is not so difficult; it’s harder to influence them.
Perfectionism is a psychological quality that distinguishes good developers from bad ones. It applies not only to the visible result screens and buttons but also to the internal implementation of the product, that is, the code.
For example, you need to add a bonus action mechanic on the payment page. A good developer would be able to implement in a week a mechanism supporting any action administered from the admin panel, with customizable conditions, timing, and so on.
But you need a quick solution to launch the promotion tomorrow and throw that code away forever a week later. You need to understand which components will stay in your product for a long time and which can be implemented for throwaway purposes and communicate this clearly to the software development team.
Sort Tasks and don’t Set Them All at the Same Time
Tasks for the software development team are divided into large (to make a new feature) and small (to fix the registration form). The general rule is never to distract a developer from an enormous task to solve a small one, even an urgent one.
Some unique professionals can work efficiently in such a mode, but most developers drastically decrease productivity due to constant switching between tasks. Therefore, it makes sense to have an alternation-first an enormous assignment, then a week of small tasks. Record small tasks as they appear but give them to software development to include them in a list when the next iteration or release is planned.
Every Developer is Different
The difference in performance between individual developers can be huge. For example, in some studies, the version of the best and worst programmers with roughly the same experience differed tenfold.
You need to understand that the same person can show excellent speed on tasks within one plan (e.g., interface extensions) and catastrophically low speed on other tasks (large-scale server-side tasks). So everyone should be given tasks they are comfortable working with. Otherwise, productivity will fall.
Be an Assistant to the Developers
An important thing will help you speak the same language as the developers. Most technical people have very organized and rational brains; they fit into a logical scheme. But this scheme will not always be convenient for your users.
As a non-technical person, you have an advantage — it is easier for you to go beyond the framework that the implementation suggests and communicate with the developers the right vision. But remember: to get your point of view across to the software development team, you’ll have to prove your ideas right with logical arguments.
Set Aside Time for Internal Changes
You need to remember that there are time-consuming tasks that you can’t see from the outside in any project, but you have to do them. It is so-called technical debt. How was it formed? While adding new features, the project acquires crutches and props.
Many tasks are solved quickly but in an unreliable way. For example, if you don’t regularly bring your code into order (this process is called refactoring) and don’t develop the project’s architecture, you will constantly grow errors after some time.
They may occur when adding new features or even when fixing old bugs. If you don’t spend time developing the project’s architecture, you won’t be able to cope with the growing number of users sooner or later.
Technical debt tasks need to be planned and executed, but how do you find the right balance between them and product development? Naturally, your focus as a funder and non-technical person will shift to new features. But on the other hand, developers tend to improve existing code endlessly and are less enthusiastic about new functionality.
Therefore, you still have to, at least on a basic level, understand the technology and the structure of your product to find a balance in discussions with developers. Technical tasks must occupy about 20% of the working hours of the software development team and go along with the development of new functionality and bug fixing.
Learn About Technology
To develop a product, you have to study its structure and the technology in general, at least at a basic level. It is vital because the technology may still be alive but not quite suitable for your tasks. And it is often impossible to find this out before launching the system in battle mode — with real users and under heavy loads.
To sum it up, you still can’t do without immersion in technology and software development as a funder. Moreover, this knowledge will give you a better understanding of how your project develops.
