Discovery Phase
Development process
Discovery Phase is a service that our company provides for the development of PRD (Product Requirement Document).
Let's figure it out together. Firstly, you want to develop a project that will provide direct profit or bring you value by becoming an instrument for your company. So the solution should work specifically as you intend it to work. To achieve this, you, as a customer, and we, as developers, must be on the same page and understand exactly how and what should be done. You may say: “You are professionals - you must know how to develop projects”, we know how to complete the project on time and with the required quality. But if you just tell us an idea, we will not be able to read your mind and develop exactly what you want. We need to be realistic about this issue.
Discovery phase is not just the development of technical documentation. During the Discovery Phase our team carries out a lot of work in different directions:
- Detailed research covering all relevant project information
- Business analytics
- Looking for best practices
- Monetisation
- Process optimization
- Infrastructure load calculation
- Development of project and technical documentation
- High-Fidelity Wireframes development
- Compiling backlog
- Development of project glossary
- Selecting most appropriate tech stack for the task
- Focus on core business logic
- Project promotion and sources of traffic
- And other necessary tasks
The discovery phase can be roughly divided into several stages. These works are carried out in parallel, but nevertheless, for better understanding, we will divide them into parts. So to say, we will show the process of work in the context.
A lot of questions
Project manager starts by asking from 50 to 100 initial questions related to the project. At this stage, we are actively supplementing the project brief. We form the sections Terminology and Technical requirements.
Often, after the first few days of discussions, the brief grows 5-10-20 times from the original. Thus, the client himself, answering questions, tells much more than was previously described in the brief by him. Also, our deep questions allow you to think about the core business logic of the project as a whole.
Note: We're not used to doing things just for the sake of doing them. We always want to help the client, point out his mistakes in the logic or expectations of the project. We state right away what will not work and what you should pay attention to. This is where the knowledge of the expertise of growth is manifested. But it all depends on the development strategy, you can read about it here.
Project structure
The start of the development of the project structure is the main part of the PRD. During this part each small detail, button, notification, background process is described. Our task is to sort out all the pitfalls of the project by analyzing and describing the full logic of the project. Then we find technical solutions to all the challenges before development starts.
Note: Many companies are content with simply describing everything they see on WF or Mockups in their documents (I can't bring myself to call it PRD). This is extremely problematic.
- This gives the developer the right to twist your arm saying that this was not described in those docs and was not shown on the layouts. Thus leaving the right to choose. As a result, you may not get what you need
- So both you and the developer run the risk of underestimating the real amount of work and the project will stop in the middle of development without a budget
- You, as a customer who will subsequently own this project, will not have an understanding of how everything works in your project
If we take 100% of the work of the development team and QA specialists, then only about 15-30% of the time is spent on developing and testing positive cases. 70% is spent on negative cases, processing of exogenous factors, data integrity checks, optimization, processing of background call-backs and webhooks.
Note: Imagine a situation. You have received a pretty estimate and an optimistic deadline. At the end of the term, the product will be rolled out to the production server. You launch a high-profile advertising campaign, invest the entire remaining budget in marketing. Drive traffic to your service/website/extension/app and suddenly a negative case (for example, a third-party API does not work, and you do not have retry set up) or an exception (for example, a negative case was not taken into account with a positive response from your own API) wastes the majority of spent resources.
We have 21 hidden tasks in the test for our front-end specialists. And one of these tasks is a negative case with a positive API response. There is a registration form where all fields are required and one of the fields is a list of positions that arrive by GET request. For example, 200 status arrived with 0 entries and all exceptions. Which shows the difference between an experienced developer and a developer with rich expertise. Even moreso, when guys with 2-3 years of experience complete a test and out of 21 hidden tasks they find only 3-5 tasks. Imagine what they were delivering at a previous job. And when you ask why this task has not been done, they say that they did not demand it from them at a previous place. We have to retrain the guys during the internship to take a self-test seriously and consider not only positive cases, but also take into account negative cases and experiences.
This is the difference between estimates and terms. It is one thing to do 30% of the work, and another thing to do 100% of the work. I think you can see the difference with the naked eye.
Background processes
Let's imagine a situation. You are developing a general plan for building construction. The task is to place an outlet and a switch for the main lighting source. And the project document just mentions a socket on the wall, a switch on the wall and a lamp on the ceiling without further elaboration. But wait, where are the wires from the distribution block? What is the cross section of the wiring for the outlet and for lighting? Where is the description of the RCD for the outlet, what category A B C will it be. Is it a bathroom, children's room or a socket for a power tool? I hope you understand me. With a common example, I would like to convey to you the meaning of describing even the simplest background processes.
A background process is what happens after some of your actions or triggered by an event or timer (cron command, queue). And it is very important for you and the developer to understand exactly how this process should take place. This is not a black box, nor is it Schrödinger's box. Here the customer and the performer must know exactly what and how everything should work.
For example, let's consider a complex purchase when goods from different suppliers are sold on your site and each has its own internal conditions for mutual settlements, fees and deferrals for them. All conditions of transactions be it monetary, logistical and notifications should be accurately described in the documentation.
Wireframing
At this stage of WF development, you can get a "tactile feel" of your future project. Our task at this stage is to show not only the UI, but also all derivatives.
- All the pages for the project
- All the UI states on each page: help text, success and failure states, exception reactions etc.
- Tooltips, snackbars, pop ups, drop down lists, autocompletes etc.
- Emails notifications sent out by the project
- Admin panel
- UI difference for logged in user and user who is not logged in
- UI states for different user roles
- Placeholder-UI and preloader
- Cases with empty values
- And many other details
Usually we prepare WF in only two screen sizes: desktop and mobile. Already at the mockuping stage, we make 3-4 sizes (2K, desktop, tablet, mobile).
Note: Many companies just show one screen and that's it. This is not correct because in this way you and the developer do not see the real amount of work, which will then cause problems in the project and these will be your problems, not developer’s. You will not receive your project on time, and the developer will simply disappear (especially if it is a freelancer or outstaffer).
The author's pain
You need to forget all the Hollywood fantasy scenes where the hero's assistant hacks the main server while sitting in the toilet of some building while the main character attaches a piece of plastic with an LED to a randomly selected wiring in the server room and it lights up green. You understand that if you jump from the roof even if you believe in yourself you will not fly like Neo (from The Matrix). Therefore, let's go down to the earth by elevator or stairs and figure out what is Discovery Phase, PRD, WF, GD, DO, CF, WPT, PS, UX, CR, ....
Now let's debunk the second myth - just because you see a button it doesn't mean it works properly. Consider a classic example. When our company started in 2005, customers often asked for a quick copy of Google: “That's one page, a search field, and a search result. What is so difficult here?” Later in 2007, we were constantly bombarded with requests to make a copy of Facebook, also in a quick way, where “clients” counted up 5-10 pages. Well, this is an obvious complex example of a complex underestimated project. Let's do something simpler and closer to our time. 2021, the client claims that in order to accept payments on the site, it is enough just to add a Paypal button on the site and in a magical way the user will be able to make a payment, and the database will be updated, web hooks will be processed, actions will be taken into account, goods will be written off on balances, the balance will increase and the client will receive an SMS and email notifications from the site. Now we are on the same page that doing this is not so simple. Right?
The third myth is that an agile approach can coincide with a fixed price which is in reality not possible neither in scrum nor in kanban, at least in our universe.
Forth one is that a 3-5 or even 15 page brief is enough to estimate a project. But it is not a PRD, it's just a brief. PRD is 150-300 pages in 9 kegel + High-Fidelity Wireframes.
Last thing. Just using big words does not help to create a really high-load project. For example, you need to create a “noSQL Mongodb project with SSR (Server Side Rendering) based on node.js and react native”. What? It's just a set of words like those used in Hollywood when the main character in the film says a set of complex terms from some area. But if you understand at least something in this area, it becomes clear to you that this is just a set of unrelated terms.
Real PRD example from our experience
Let's look at an example. As you know, our guys work in 7 offices of the company (2 offices in Tallinn, Estonia and 5 offices in Kyiv, Ukraine). Recently we greatly expanded our team and needed more space to fit everyone in, so in early January we found a new bigger office space which needed a renovation. As everyone we encountered questions of the deadline and estimate for the repairs. You can’t just show the foreman and office manager the premises, tell them what we want and expect to receive a deadline and estimate.
Therefore, we took it upon ourselves to develop a 3D model of the new office in SketchUp. We thought of every little thing up to every lightswitch, camera, even all the posters on the wall and their prints. Then we prepared a complete and detailed document where we described all the work that needs to be done, provided the screenshots with precise technical measurements of what and where should be installed. We also made a list of all furniture, equipment and materials necessary for the new office. Painstakingly described every small detail like wall color, furniture color, location of cameras, lighting fixtures, antibacterial lamps, alarms, electronic locks, etc. Once we made sure that we covered everything we sent all the information for estimation. And when we met with the foreman and furniture maker in the premises, they provided us with a full estimate, a repair plan and a deadline in a couple of days. They guaranteed an accuracy within +/-10-30% which is not different from our approach.
As the real practice of successful projects shows, everything should start from the PRD.