This is part 3 of the Building successful MVP with offshore team.
Remember – the more details you let the developer interpret freely and assume, the more likely you are going to fail. Think about it this way – if you decide to build your own house, will you tell the builder that you would like to have a gorgeous open floor plan house with 4 bedrooms? I guess not. You will go through each detail of your dream house before any construction starts.
Product manager converts your vision of the application into the exact specification of what user will experience. This includes the exact steps of how a user navigates through your application, mockups of each screen, any data validations and so on. The key word is “exact”.
Let me give you an example. It’s not enough to tell a developer that you need a Log In functionality. You should provide the exact details about it:
- Should it accept email and/or username
- Any restrictions about username and password
- Error message if Log In fails or any field is missing
- Should user be able to stay logged in (Remember Me option)
- Should log in ever expire
- How you are going to handle “Forgot my password”
- and so on and on …
“But this is too much work to describe all these details. Shouldn’t developer already know all these?”. No, but he will assume, and that’s not what you want. Believe me, you will do this work anyway. It’s just a question whether you will do it upfront or after the coding is done, the result is not what you need and it should be rewritten. Doing this work upfront saves you time and money. It also gives your QA the exact testing plan.
Now the question is how can you nail all these details upfront? It’s not that difficult, just don’t try to invent a bicycle. Find any popular application that has a similar functionality and check how it works. For our example with Log In, you can try Facebook, Gmail, Instagram or Quickbook. Try all possible scenarios, write them down, apply for your own case and pass them to developer and QA. You should discuss this specification before any development is started. Make sure that it’s very clear for developer and QA that they should not assume, but ask.
Be proactive and you will succeed.