Develop your product twice as fast ...with a sheet of paper

Table of contents

    Get a free consultation

    Building a new software product can cost a lot of money. But instead of looking for a cheap development team and cutting corners we suggest you take a new approach to the production process itself. Here's how.

    During our talks with different startup founders we’ve noticed one thing they have in common. Building MVPs take usually twice as much time as planned. Why is that? Does it mean startups hire incompetent developers? Maybe they don’t really know what they are building? Or maybe they change their mind all the time?

    No! (Actually, the right answer is “Yes and no”). The biggest reason why projects take up more time and money than estimated is because of an insufficient planning phase.

    Inside the product owner’s head the vision of the product is crystal clear. But it doesn’t mean it can be easily transferred into precise and to-the-point technical requirements that engineers need to develop a piece of software. On the contrary. Often developers have to deal with contradicting and fuzzy requirements that don’t cover the whole project.

    Vision vs execution


    Image credit: dribbble.com/chelledixon

    A lot of the time startup founders come up with an idea they communicate to the developers on a higher level. For example: “I want to build an app that hosts user files in a secure place.” While this communication is fine for getting the main purpose of the product across it’s not detailed enough to start developing a product right away.

    But this is exactly what happens. After a brief planning phase the team starts working. But when a planning phase is too short and lacks details this leads to multiple costly product overhauls during development: things work worse than expected, UI is a mess, user experience is abysmal.

    In order to save money and your time let's see how we can optimize the whole process.

    You need a better plan, not a Plan B


    Image credit: dribbble.com/wikensa

    I understand why both dev teams and founders hurry to the development phase. This is where the real work is done, this is where results are visible, and something tangible is created.

    Planning is boring. It’s a lot of work that doesn’t bring results immediately. With this thirst for action that most founders display it’s no wonder that planning is done as fast as possible. But planning is not a waste of time. It is a vital part of the project that will help you work faster during all the other phases.

    Iteration during development means rebuilding and reimagining the app on the go. Changes take days or weeks to implement, test, and deploy. This process eats up both your budget and your money delaying the release.

    So here’s one way of doing things:

    • Coming up with a list of features
    • Implementing it
    • Iterating on the features further

     

    But a more efficient approach is this:

    • Coming up with a list of features
    • Analysing the features
    • Iterating on the features at the drawing board
    • Implementing an optimized feature list

    Instead of iterating countless times during development you can do that on paper. Sure, the planning phase will get longer, but a more detailed and thought-out plan makes production faster and cheaper. And instead of weeks of additional development time changes take hours or days to implement.

    How to deal with a layered feature hell


    Image credit: dribbble.com/karenyoojin

    Feature depth is not the same as feature creep. You don’t add new functionality to the project, you just describe the features you already want in a better way.

    Non-tech people often don’t recognize this need for an in detail analysis and description of every feature they want to implement in the app. But the development team cannot build a piece of software efficiently without detailed and non-contradicting technical requirements.

    Non-technical product owners often don’t see the depth of the feature they need to implement. Until it’s too late. This misunderstanding leads to a number of issues:
    wrong cost and time estimates for the project (something that seems easy for a non-tech person could actually take a long time to implement in a product);
    poor planning – resulting in a short list of main features that need to be way more detailed and thought out in order to build an app.

    You don’t want to find out late into development that your choices were bad. You want to do it early. And correct yourself when it’s cheap – at the drawing board, not when your product is almost done.

    Without effective planning stage there are a number of challenges that the production team has to deal with:

    • use cases and outcomes that are defined poorly or are not defined at all;
    • instead of planning and consulting with experts founders default to common sense – but they forget software development is different, programming-specific challenges may be harder than they expect;
    • the mentality of working hard instead of thinking hard, combined with a constant state of being in a hurry;
    • the pressure to show work and show tangible progress before anything else;
    • initial optimism of the team – a tendency to brush off potential problems or dismiss them completely.

    Eliminate bad planning in your project


    Image credit: dribbble.com/lobanovskiy

     Improve your development process and ensure that you don’t extend your budget or delivery time due to bad planning:

    • involve a system analyst early on to make sure all requirements are logical and consistent with the previous ones;
    • consider a strong UI/UX expert – prevent costly UI overhauls of an MVP or a live product;
    • discover an optimal layout and logic for your app early – deconstruct the complexity of the main features by building a frame-by-frame mockup for each user story you plan to have in the app.

    Iterations during the planning phase will help your project in many ways:

    • good planning can save you from spending 2-3 times more resources than you expected;
    • project owners are directly involved in the planning process and make informed decisions with the help of experienced UI/UX experts and system analysts;
    • iterations during planning don’t waste developer time or effort – it’s significantly cheaper to change things on paper rather than to constantly rebuild a working app;
    • a longer planning phase allows to better shape out technical requirements, eliminate contradictions, and cover the whole functionality of the project more thoroughly.

    Instead of discovering new design issues during active development save yourself both time and money and dedicate more effort to your planning stage. Uncover these issues at the drawing board, correct them, and move on to building a great product.

     

    Recommended for you