Every company tells their clients how their workflow is organized. They do so because they want to explain to their clients the great benefits they’ll get when the process is established exactly this way.
Understanding the work process is also important for you as a client. When you’re searching for a service provider — no matter what service you’re looking for — you want to ensure that the service provider you choose is an expert in their field. Second, you want transparency about what your cooperation will look like. You want to be sure that everything is under control and that you can rely on your partner.
I would like to introduce you to how EGO works with our clients. And I promise that you’ll stop the exhausting search for your ideal software development partner by the time you get to the end of this article.
That’s why we do everything differently now
In the past, we’ve faced situations in which we were already discussing the technology stack and preparing project documentation when we found out that the client had chosen a product implementation that wasn’t quite right. The reason varied from lack of market and competitor analysis to poor understanding of the users’ needs. But regardless of the reason, the result was that the wrong tool was chosen to reach the business objectives. If we had left things as they were, this would have resulted in a broken development process, which would have been unpleasant for both our team and the client. We saw this happen over and over again. And nobody ever wants that to happen. Therefore, we changed our strategy for interacting with our clients.
How we work now
In order to create an awesome product that will delight users and beat its rivals, we started doing intensive analytics at the initial project stage. As a result, with some clients we’ve determined that it’s more efficient to launch a web-based product instead of a mobile product. With others, we’ve had to advise modifications to product functionality.
You may be wondering why we would suggest such dramatic changes. Let me explain. Imagine that a man comes to a tailor and orders a bespoke suit to wear to his daughter’s wedding. While sewing the suit, the tailor learns that the wedding will take place in Hawaii. He tells the client that it would be more appropriate to wear a fashionable bright shirt, shorts, and flip-flops instead of a suit for a wedding on a tropical island. The client agrees and later is very happy because it turns out that shorts and flip-flops are great for the beach party and, more importantly, the sand isn’t getting stuck in his expensive shoes!
Usually, a client has hypotheses about their users’ needs and app features that will meet those needs. We check these hypotheses and prove or disprove them to come up with the best product solution. This is how we work. We consult with our clients and help their businesses grow, be more innovative, and be more successful by better understanding their customers.
What do we do?
Stage 1: Takeoff. Analysis and product consulting
During a kick-off meeting, our client presents their product idea and shares their thoughts on how it should be implemented. They also show us all the documentation they currently have to convey the product concept to us. This might be requirements documentation, a product presentation, wireframes, sketches, screens, specifications, user stories, or even a rough description or an idea written on a napkin.
After that, we dive into thorough analysis. We start with a close investigation of our client’s market and customer profile.
Analyzing our client’s domain
At this point, we work with our client to learn more about their business by
- investigating the specifics of the business;
- conducting market and competitor research;
- taking into account the terms of project funding.
Writing customer profiles
Our client’s customers will be the product users. To make the application useful and desirable, we first of all look at it from the users’ perspective. If you want to get a deeper understanding of your customers’ needs, answer the following questions:
- What kinds of issues do your customers have?
- What benefits do your customers expect to receive by using your app?
- How can you solve your customers’ issues and give them these benefits?
Setting goals
The next step is to figure out the business goals that our client hopes to achieve with the product. During an interview with our client, we help them structure their thoughts and convert them into precise goals, then write them down.
Based on this list of goals, we create several mind maps. We put one central goal in a mind map, then add branches with second-level goals flowing from the central goal, then go deeper, writing down all subgoals until we reach goals that are directly related to app functionality. At this point, we define the exact metrics that will show us when a goal has been accomplished.
After these specific goals are set, we put them on one board along with our users’ needs (defined in the customer profile) and a description of the app’s functionality. During a brainstorming session, we establish the relationships between all these components.
- Will the app features provide users with the benefits they desire?
- What features are useless and what crucial features have been missed?
- Will this functionality help reach product goals and achieve business objectives?
These are the questions that you should answer to create a useful product.
With our sights set on the end product, we cut out unnecessary functionality until we’ve shaped the product. We make sure that every product goal is covered by a corresponding feature.
It’s also extremely important not to overload the first version of the product with features that aren’t essential. It’s wiser to focus on non-essential features in the next versions after the first has already been released successfully and the goals of the MVP have been achieved.
These goals should be not only specific but also measurable. We’ll determine the indicators of project progress in the next two stages. Reaching these KPIs will be an indicator of achieving our goals.
Setting KPIs helps us to evaluate the effectiveness of achieving the key business objectives. KPIs give answers to the following questions:
- If one of the objectives wasn’t achieved, which of the hypotheses was wrong and what lessons can be drawn?
- Was the list of essential functionality determined correctly, or do we need to revise it?
- If the objective was achieved, what else we can do to boost the success?
In our next article, we’ll also tell you about creating a business model canvas and how it impacts product success.
After these steps, we combine the domain analysis report, customer profiles, and mind maps with goals and functionality and discuss them with our client. Since the client, who is usually the product owner, has deeper knowledge of their domain, we consider the results of our analysis in light of our client’s knowledge and make sure that we’re on the right track.
These steps take up to five business days and are carried out in the form of a workshop with our client. After that, we need about one week to analyze the data and draw up our insights. We call this stage Takeoff. Once we’re finished with the Takeoff stage, we have a detailed specification document for a mobile app and clear business goals for the product. With this roadmap in hand, we’re ready to move to the next stages.
Stage 2: Choosing the technology stack and defining the development approach
Choosing the right technology stack is the key to a project’s success. Choosing the wrong technology stack may lead to failure. The result of this mistake can be costly and may delay development for months. But why does this choice matter so much?
Let’s get back to the main hero of the story from the beginning of this article — the father of the bride who was happily dancing at the wedding dressed in his fashionable outfit. He eventually got a painful blister on his foot after he overdid it dancing the boogie-woogie (of course he overdid it — he asked the DJ to put it on repeat for the third time!). The blister made him suffer so much after the wedding that he decided to see a doctor. The doctor offered him a choice of several treatments to get rid of his problem. Our hero was tempted by one of the fastest and cheapest options, so he chose it without hesitation even before the doctor had finished the consultation. After a while, it turned out that this method was healing his blister quickly and cheaply, but it had a side effect — a terrible rash throughout the body! He should have more carefully compared all the options and learned about possible risks. As a result, he spent money treating a new issue as well as the initial one.
Likewise, making a superficial decision concerning a technology stack for your project may cause negative consequences. If you place a bet on a programming language or a framework based on a desire to make the development process either fast or cheap, you should be ready to face some difficulties in future.
One app that needed to change its technology stack was Airbnb. You may find over time that your technology stack is unable to meet your original goals and solve emerging technical challenges. It’s unfortunate if this happens, but it’s also a learning experience.
It takes time and effort to find the right language or framework at the very beginning of your project, but it’s better to think twice and rethink it again than to overpay down the line.
That’s why at this stage, we engage our technical leads and developers to predict possible project risks and determine solutions to avoid them. They decide what programming languages, tools, and frameworks will be most efficient for developing each particular product. In this way, we lay the foundation for product success.
Stage 3: Product visualization
After all the preparation work is done, it’s time to bring our client’s idea to life. Our designer and project manager start working together on the Blueprint. You can get to know more about our Blueprint in a dedicated blog post. At this stage, we create interactive wireframes (as a clickable prototype), the concept, and the Blueprint document, which contains the outcomes of the Takeoff stage. We’ll go into more detail about this phase in our next post.
These are the deliverables for the product visualization stage:
- Requirements analysis
- Basic mind maps
- Wireframes for key app flows
- Style and branding options
- Design for 3 to 5 key app pages
- Technology stack suggestions
- Requirements summary
- Development roadmap and estimates for the first phase of development (MVP)
You may ask: Is it possible to do without all these long preparatory stages? Can’t you just quickly discuss the vision with me and put the project into development? All I need is a working prototype.
I want to remind you of the story about a man who buys a chair at IKEA and, when he gets home, decides that he’s brave enough to construct it without the manual. “It’s just an ordinary chair,” he smirks. After a while, the mission is accomplished. Without the manual, he has constructed a nice coffee table. Not bad, but not the exact thing he wanted. That’s why my answer is this: It’s better to use a detailed roadmap to reach your precise destination. Otherwise, you may fail, and the price of failed development is too high.
As you can see, our development process allows us to deliver the most winning solution. The results of our analysis and product consultations, which we conduct during the Takeoff stage, pave the way for the development of a product that will provide exceptional value to its users — and, of course, fame and fortune for its owner.
In our next blog post, I’ll focus on choosing the technology stack and visualizing the product to give you a detailed picture of what those processes look like. Stay tuned and let us know if you have any unanswered questions.
If you have an idea for a project, we’ll be happy to discuss it with you!
The Store
Check for more
