Production Diary 2.0 – a startup within a startup

What is more difficult: launching a startup project in an “open field” or embedding it into a finished product? In fact, everything is equally difficult.

When you start something from scratch, then you have room for creativity, at the same time there is nothing – you need a lot of “human resources” to launch, and the “bonus” is potentially no users.

In the case of launching an internal startup, a new direction of development within the product, we have: architectural constraints, the need to integrate beautifully so as not to affect the existing unrelated functionality, the foundation and the few users that we heard – they are waiting.

I want to tell you about how it goes launch of a new direction of MyWarehouseManufacturing 2.0. From a business point of view, the topic is very curious and interesting. I’m telling you live. This article is my view on the results of the first two weeks of work, so I can immerse myself in the fire of events and not miss a single joke.


  • we
  • Where do business requirements come from?
  • We design by predicting the future
  • Coffin manufacturing and data model
  • how not to break find a common language with a business analyst if you are an architect
  • We worked, but no. Car and fish. What common?

MoiSklad company – for over 13 years has been developing and selling a web service that makes life easier for small and medium-sized businesses. The service helps to keep inventory, manage sales and purchases, print documents necessary for running a business, and much, much more. We have an established and constantly developing development process. Tickets made on the first day of work (tasks in common language) may be on sale tomorrow. The product is large and complex, users are actively sharing their wishes. We figure out how to make a service useful for people – and we do it. And now we are updating the production block! We are the Production team.

Characters of the first stage:

  • Askar – CEO
  • Oleg – technical director
  • Maxim – product owner guiding us
  • Timur is a business analyst who knows production processes
  • Maxim – team lead of the development team
  • I am a systems analyst


I will briefly retell the introduction that on the first day of the sprint, October 22, 2020, we heard from Askar.

Production in MoySklad has been around for a long time and has users. But it is done in a minimal way. You can create routings and, on their basis, either reserve goods in the warehouse for production, or immediately write off goods and produce finished goods. It’s all.

For a long time, the sales department and technical support broadcast complaints and wishes for improving production from users. Despite this feedback, the number of users is growing. Production is often launched in existing organizations that already keep records with MyWarehouse and do not want to change it. This is one of the main reasons the number of users of the current production is growing: working with two programs is outrageous.

In February 2020, Timur (now our business analyst) wrote to MoiSklad (now our business analyst), who was then working in real production, with a description of “how it should be”, a prototype and a proposal for cooperation. As a result, Askarom decided to approach the development of this direction thoroughly and launch Production 2.0 – updated and smart.

Let’s go into production

For a long period, Timur analyzed complaints and wishes from users, interviewed support and sales staff. Based on the results, I formed a list of functional capabilities that will gradually appear in the Production of MyWarehouse. They are already described as business requirements and this could end – just take the developers and do it. But it’s not that simple.

MyWarehouse is large and complex inside, and business requirements are changing. So our team set itself at the start such tasks:

  • View the entire scheduled backlog to predict the future realize what awaits us
  • Design a data model to define underlying entities, fit into the current model, and avoid catastrophic future migrations
  • Define complete custom scripts, key features
  • Make UI prototypes based on analysis and design
  • Create development tasks and do

Having looked at the backlog, we, of course, imagined a picture of the world, but until you start doing a specific task, everything will remain at the level of abstraction. By the way, this is how many startups die: they plan to do everything at once, at once and for everyone, they sit more in discussions “what will happen tomorrow”, instead of pull out one wireframe puzzle and start working it out. So, based on the results of reviewing the backlog, using the ranking method, we have one business task for the first sprint, which changes the entire current production. It will grow on a very large scale.

What helped you take the first step?

Interface layouts in the form of an Excel table, which were “drawn” by Timur, our business analyst – a representative of the users of MySklad, who did not use it as much as we did. His product vision helps to understand what people want to see on the screen, and his fresh perspective brings interesting ideas, replacing our “let’s reuse”. With these mockups, we started to touch processes and design a logical data model.

Recommendation: before designing the system from the inside, draw custom UI layouts in any form, even with A4 pencil. Yes, they will change 100 times, and in general a normal UI / UX designer will fix everything later, but they should appear to help.

Everything rests on her. Data model

While we were designing the data model, we found all the possible problems that could arise, identified all the main processes that it should cover. We used the model to test a complete list of known business requirements.

If this step is not taken at the start of the project, then there are chances at some point “Discover America” ​​or remake everything… The data model is something more elementary than the foundation, it is the Earth, and everything in general rests on it.

Discussing the first approximation of the created model on brainstorming, I immediately indicated: imagine that we are doing everything at once (and yesterday). So, we took another entity and found out what can happen to it, who can influence it, how it can be changed, how it affects accounting, how it is related to current entities in the system, where connections can appear suddenly. Important be able to ask the right questions.

In general, the discussion was structured something like this:

  1. For the next entity I ask: “What is this?” and “What can we do about it?”
  2. Timur tells us about related processes, shows models, gives examples.
  3. Everyone asks many, many questions: “Is it possible so?”, “What if …?”, They are surprised, and sometimes shout “It is not allowed!”
  4. Timur convinces that it is possible and very necessary.
  5. From an example about assembling a cabinet, we move on to an example about coffins (“And if we make coffins from Australian oak, and we are ordered a modification from pine …”).
  6. We laugh, we come to a compromise, we finish drawing related entities in the data model, we describe the key parameters, and we leave notes “to clarify later”.
  7. We fix in the article “Questions and Answers” decisions on business requirements and restrictions, if they appeared during the discussion, or vice versa, if they were removed.

We made a logical model. As a result, we got such a small monster with notes and clouds.

Recommendation number two… If a startup is launched from scratch, then there is room for creativity and you can take any experienced developers from the labor market. When creating a startup in a finished product, the team must at least know the basics, be able to research and not be afraid of it. Do not launch internal projects with new people in the early stages – this can be dangerous for an existing product. Maxim and I previously worked in other teams of MySklad. For Maxim, the role of the team leader is growth within the company. My assignment in MyStore is to explore everything, everywhere. Therefore, we had a lot of questions for Timur. The more questions, the more responses. The more answers, the more likely you are to get a more reliable solution.

Kill the architect in yourself and learn to hear

A little about the problems that arise during the design. Due to professional deformation in the first week, we had a lot of misunderstandings in the team: Development vs Business. Knowing the problem, I tried to shout less that we did not fit into the current architecture, but still shouted. And Maxim shouted.

What do developers want from the business early on? Confidence! Many times we have smashed Timur’s confidence against the rocks and led him away from the intended business requirements to trying to make what is, or make it easier. You can not do it this way!

The concept has already been worked out, and we, so smart, came and destroy everything. Thanks to our product, who appeared on time and slowed down pressure on Timur, arguing that all business decisions were made long ago. And later, I finally turned off my usual systemic thinking and took the side of “what the business needs”, pulling my fellow developer along with me.

As soon as this internal transformation took place, we began to torture Timur correctly. And when he himself wanted to simplify something, we asked to consider the option “complicate”. And yes, all this happened precisely in the process of designing a data model and testing business requirements on it.

Recommendation number three: business developers expect confidence. If you are a business analyst and represent a business, or you are a business customer, be firm in your decisions to the last, no matter what the developers say. Simpler doesn’t mean right! If you make it easier today, then tomorrow the improvements will result in very large sums. It is better to spend a little more in the beginning and pour all your soul (wishes) on your developer than suffer later. The developer must be aware of the potential future!

Don’t put it off until tomorrow. NEVER!

As soon as we made the data model, more or less approved the processes, allocated screens and functions for the first development tickets, it’s time to call Oleg, who understands the best of us and knows the architecture of My Store.

We had to discuss migration for current users – there were too many questions about it, and I don’t want to run two versions of production at all. And then our command confidence again dropped from heaven to earth. For a long time we were in doubt about the basic business question: can the result of production according to the technical map be more than one product? It seems that we have already agreed with the business that only one product can be the result.

One more mistake … We knew that we had to check the percentage of parser users on the market, but we delayed until the last, although we had even prepared SQL queries. If there is a prototype on sale and you can test the theory on real data, check immediately!

If I did not write, but spoke, it would sound like (read with expression): “M … Well … How to say … In short … Here … Every third …”.

The technical map, by the way, is the basic entity around which all processes revolve. We were lowered not just from heaven to earth, we began to sink to the bottom. The heart almost stopped.

What caused this situation? We all knew that this was possible in current production, but keeping records on such technical maps is problematic. Despite the presence of an example about disassembling a car from Maxim, our product, Timur convinced: this is a rare case and in general there are few such users. Oleg was immediately against the rejection of such an opportunity. It was at his prompting that we finally got to the sale in order to test the hypothesis. Yes, and in this demo of architecture I remembered about the disassembly of fish into the head, tail and fillets.

At the end of the first sprint, we came to the final decision, and very soon our data model will allow us to design in detail and start development. The layouts are detailed, we involve colleagues in testing and UI / UX. We continue to create!


To successfully and quickly start a startup project:

  1. Explore all known backlog to know the future.
  2. Pick a fundamental challenge that does / changes everything.
  3. For an internal startup, you need to involve a team with experience in solving other problems in product development.
  4. Listen to business and give your business analyst the elixir of confidence. Business requirements are more important than system constraints. System limitations can always be overcome (that’s for sure)!
  5. Before designing anything, look at the system through the eyes of users – you need a rough UI layout, which will definitely be changed.
  6. Design should start with the data model
  7. If it is possible to test the theory, test it immediately, without delaying until the last.

About production in MoySklad

Similar Posts

Leave a Reply