During my time at Apiko (over 2 years so far), I’ve worked on projects that ran the gamut in terms of complexity and team size. From close-knit operations focusing on a single issue, to huge teams dedicated to tackling multiple pain points, I’ve seen it all.

Despite the varying sizes and scopes of each project, all of them have been united by one factor: mutual understanding between a founder and the development team is critical to success.

Between founder and designer, it’s very difficult to completely and clearly express what you should expect after development. Managing this expectation is a continuous process that requires your vigilance to get a positive outcome.

In this article, I want to share my experience of working with diverse founders and projects in order to highlight how critical good synergy with your developers is to your success. I’ll describe the main stages of software development (for those who need a refresher), and offer some tips on how to fight misunderstanding and achieve synergy between you and your developers.

How to communicate your new idea to designers

So, you’ve cooked up a stellar new idea. It’s awesome and promising. Now, you just need to communicate it to the developers. To avoid any misunderstandings and ensure that you are on the same page, let’s try to be as clear as possible.

Here are the main steps you should take to shape your idea into explicit specifications:

Create the initial requirements

Any serious project starts with defining the problem it solves and describing the solution you offer.

At this stage, founders describe the kernel of the problem and their vision of how it can be solved. The developers analyzes the problem and, based on the experience, offers you the project execution plan.

If you are pushing a new product, we recommend starting from concept development. This will help you to identify whether there is a market need for your product.

💡 Advice: Don’t insist on using certain technologies, features, or solutions only because someone else recommended it to you. It’s better to discuss the technologies with your development team, weigh all the pros and cons, and choose the technology best for you based on the mutual discussion, personal experience, and any already-developed products you might have.

Create a list of features

After the main concept of the product is clear and validated, it’s time to design the technical specifications.

There are two options of approach here. First: the developers offers you their ideas on the essential features of your app, based on the market research and competitor analysis. Second: you define these features together with your team.

Whatever you choose, the features list should be discussed in every detail. Here are some important factors to consider:

  • Development time
  • Technology Stack
  • Budget

💡 Advice: It’s difficult to predict all product aspects, so try to build the product foundation with the most important features in mind, and then scale it based on the users' feedback.

Choose the technology

In my experience, founders often come to the discussion with technology they are dead-set on using. This is usually based on a couple of factors:

  • Recommendations from friends or colleagues
  • Reviews found on the internet
  • Trends in the industry

First and foremost, relying on friends' recommendations is not always a good deal. Your friends’ and colleagues’ projects likely have critical differences to your product, and choosing the same tech as them simply because they enjoy or trust it doesn’t mean it’s the best for you.

Reviews are also not very reliable, as they are completely subject to personal opinion. When describing technology they enjoy, people often highlight the benefits and look away from the drawbacks. When reviewing technology they do not enjoy, people highlight the drawbacks to an extreme. Overall, reviews are highly subjective and often misleading.

Finally, trends change with lightning speed, so relying on them is also not a good idea. Picking the trendy option simply because it’s promising and cool won’t help you when you need a real tech-product fit.

💡 Advice: Before choosing a piece of tech or tool, carefully research all its strengths and weaknesses. Remember, there are no perfect tools; your task is to choose the most optimal and suitable ones for your project.

Start from the MVP

Remember, 80% of the startup gets done during 20% of the total effort you put in. This approach may be applied to many areas, including the software development.

Here is the thing: it’s nearly impossible to guess when a product is “finished”, as most of them are “live” and founders continuously modify and improve them. Testing for this theoretical finished product is almost worthless, since the plan will change so much on the way.

Testing from the MVP helps you to create a product with the most basic functionality ( a control, if you will), with the intent to scale in the future.

Such an approach has also an economic value: you avoid the development of a large number of features, which could prove to be superfluous and not core to the product’s function. These extra features could cloud your A/B testing, and cause your experiments to yield subpar or (even worse) inaccurate readings. You can identify a feature that isn’t in your MVP by putting it up against these three criteria:

  • Functionality that will not be used in the beginning.
  • Functionality that doesn’t influence the project’s main idea and concept.
  • Functionality that may turn out to be unhandy for the end user.

There are a lot of materials out there about MVP benefits, but the biggest value is that you can test your product on real users, understand and practice what things they really need, and save your startup from superfluous features that could cost it time and money.

💡 Advice: When developing an MVP, make it scalable with an opportunity to add necessary features as your product grows.

Design software architecture

The project development should start with architecture design. Architecture is a set of solutions about the organization of a system, its components, and interfaces.

It contains the groundwork for the main features’ implementation and the product’s future scaling.

💡 Advice: Don’t skimp on shallow architecture design. Badly designed architecture can lead to unpredicted risks and longer development time.

Architecture design may seem to be a vain waste of resources at first glance, as you don’t see the final result. However, this is a fruitful investment, as a thoughtfully designed architecture will simplify the development, reduce its cost and time, which are significant metrics for customer.

💡 Advice: When designing an architecture, take into account not only primary tasks, but also those ones, that will potentially come in handy in future.

If you skip the architecture design when developing a large and scalable product, you risk ending up with constant product reorganization and rewriting. This, in its turn, leads to bad code quality and longer development time.

Proceed to development

There are a lot of software development methodologies out there. At Apiko, we use Scrum methodology. The tasks are distributed among the team members and are timeboxed to two weeks. This time span is called “sprint”.

At the end of each sprint, the team analyzes the results and presents them to the founder. The team analyzes its progress and thinks about how to improve it. Here are some of the benefits of this approach:

  • The team conducts a regular self-analysis of its work.
  • Product owner always stays tuned for any updates, risks, and results.
  • The development process is regularly improved, which increases the work efficiency.

💡 Advice: Don’t keep your list of requirements static. You can correct and improve it based on the experience and obtained results. But before making any changes, discuss it with your development team. Things that seem simple to you may be difficult to implement technically.

Don’t ignore testing

Testing is an integral part of any project that is applied on each level of the software development cycle.

There are three main types of testing. The first type is manual testing. Just implemented features should be manually tested before going live.

The second type is automated testing. After any change, the app will automatically execute tests and report malfunctions. Automated testing helps to immediately eliminate errors and mitigate risks.

End-to-end testing is a type of software testing that automatically checks the entire flow of application from the user’s side. E2E testing identifies the performance of all system dependencies and components as well as its interaction with external systems in a real-life scenario.

💡 Advice: It’s a common mistake to neglect automated testing. Avoid this mistake at all costs. It will help to prevent bugs in the early stage of development and verify the results of the end-to-end process flow.

Scale and monitor your product

Finally, when you have brought your project to light, the main power goes to your users. As I’ve already mentioned, it’s very difficult to predict everything at the beginning. After your project is released, listen to the feedback of your first users and adjust your product accordingly. This last step is arguably one of the most important; staying on top of issues and keeping your product satisfactory to customers is just as important as building the product itself.

Wrapping Up

I hope you learned something new about how to develop your new idea, and how best to promote synergy between you and your designers. If you have any questions, comments, or stories, feel free to post them in the comment section below. Thanks!