How to become a product manager. Part 2
In the middle of November, our friends from Sports.ru launched a course for those who want to become a product manager of mobile applications. Among the lecturers are employees of Sports.ru, AppFollow, Aviasales, Uber and other cool guys. Throughout December, a student at kirillkobelev teaches how the course is being taught. Today - insights from the lecture on the stages of application development.
- ... Here are just, brothers, to get used until dark. S. Galanin.
In the last article, I explained why we need product managers, where they come from and start working on the design of the application. My inaccuracy elevated Anton Baitsur to Aviasales sales director and gave him an ambiguous advance payment (but in vain). About Anton’s lecture next time, but for now I’ll see you a little more and describe the stages of developing an application based on the story by Sergei Kuzmenko from Cassby .
')
I think, I will express the opinion of the majority, if I say that little is valued so highly and remains in memory as long as cool merch. If you managed to combine simplicity, beauty and meaning in it, this is a great success. At the very beginning of the lessons we got a sticker, the content of which was obviously borrowed from the slide of Sergei Kuzmenko, - compare the two pictures below:
Jokes, jokes, but during the course all students work on their mobile application, and I feel this sticker will be a useful teaching material. It’s time to estimate what I’m already prepared for and what else to think about at each of the development stages.
In the comments to the first article, it was correctly noted: it is important to write a good, detailed brief. From the very beginning of work on the application, you should have some kind of tactics :) At the concept stage, it is important to understand exactly what you are doing and for whom, and what perspective - bright or not - you draw. I recommend to approach the issue of perspective from both sides: the user and the developer.
One of the first documents that you have to create will be a business plan, at first less detailed, but overgrown with more and more nuances: how to pay for the work of the team, what expenses are coming and at the expense of what they cover. For example, I am working on an app for a reward program for interacting with a brand. This is a small side project, and for me the efficiency of financing and team building is especially important. So far my working version is to work out the concept of the application as much as possible and to bow to the commercial director of the company where I work, in the hope that he will see the potential for investment.
In the content of the concept is useful to lay a grocery roadmap and a description of the minimum viable product (Minimum Valuable Product). In program management there is a business case concept similar to our MVP: consider that MVP is a tool that allows you to check at any time whether it is worth going further.
It seems that only the lazy was not joking at the expense of the Russians, who do not read the instructions for assembling home appliances. But if you are counting on success in creating applications, the documents will have to not only be read, but also written.
Layfkhak: it is completely not obligatory to make long cloths; terms of reference may (and should!) be short, convenient, unambiguous, unambiguous, relevant. The value of this document is strongly tied to time, so you should not make it endless.
Here is an exemplary list of what should be taken into account in the TOR (examples from my application in brackets):
An analogue of the well-known dilemma is the question of what to do first, texts or design. The arguments on both sides are iron, and judging by the recommendations of all the speakers of the course (“Do not leave ... at the end”), we will have nothing to do at the end of the application development. My humble opinion: you first need to create a user story, then headlines, then design on flowcharts, then full texts. Of course, the right to use in the design development is not Lorem ipsum, but a substantial text, but it would be an exaggeration to expect that this version of the text will live to a release.
In working on the text, particular attention should be paid to integrity (not to say “consistency”) and key parts of messaging, such as the name or slogan. If possible, write key scenarios yourself or at least get involved in working on them to the fullest.
The second in chronology, but perhaps not the least important step is careful planning of the content. From the very beginning, fix the correct requirements for it (text length, image format, video volumes, etc.) and the volume required for launching. Determine what content you will release, how often and who will be responsible for it. As an illustration, I’ll say that I expect to maximize the content of branded sites in my application, ensuring a constant flow and forming that notorious integrity of communication.
I will not dwell on the design stage. If you want to learn more, look at the piece, written on the basis of the materials of Maria Mikhalchuk , in the last article. Let me just say that it is important to remember that the content is always owned by someone, and some platforms (yes, Mr. Cook?) Watch this especially closely.
For many people, a webmaster, front-end, back-end, full-stack-developers and just “computer scientists” are almost indistinguishable. I think Habr is the last place where you need to tell who of them is doing what. I will allow myself only one advice, referring to the opinion of Sergei Kuzmenko: if you are a product manager and your possibilities are very limited, hire a front-end. Pay special attention to his knowledge of different browsers, mobile OS and the experience of implemented projects. An obligatory skill is also the possession of Photoshop and in general love for exercises with design.
And once again about TK. Make sure that you give the developer a complete description of the tasks, a well-developed design and close to the finished content - then the output is likely to get a testable version of the application.
Returning to the idea that the product should be launched while it is still a little embarrassing for it, I note that the key word here is “a little”. Finding balance remains the most important task for the product manager. Launch alone is not enough, the quality of the product itself must constantly grow.
Here are some test options that are relevant specifically for mobile applications (again in brackets are illustrations for my example):
Relevant and current test plan is a very, very good indicator of project maturity.
All the above steps will go smoothly if you have a good team. It seems that in terms of lectures there is a separate topic on the recruitment of employees, so to save time, I can only say that now a lot of attention is paid to social relations and the common interests of team members. You have to go through a lot together, so it is important that this path is comfortable. Trite, but shared values, openness and a positive attitude provide a significant share of success in the release of the application.
In conclusion, I will give a short release checklist :
Well, arrange a party if everything goes well :) Next time I will talk in more detail about the internal processes of the product team, about working with mobile stores and try to show my work on the screens and description of the application.
Thanks to Appodeal for the pad and Mark Tenu for the experiment.
- ... Here are just, brothers, to get used until dark. S. Galanin.
In the last article, I explained why we need product managers, where they come from and start working on the design of the application. My inaccuracy elevated Anton Baitsur to Aviasales sales director and gave him an ambiguous advance payment (but in vain). About Anton’s lecture next time, but for now I’ll see you a little more and describe the stages of developing an application based on the story by Sergei Kuzmenko from Cassby .
')
Zero to release
I think, I will express the opinion of the majority, if I say that little is valued so highly and remains in memory as long as cool merch. If you managed to combine simplicity, beauty and meaning in it, this is a great success. At the very beginning of the lessons we got a sticker, the content of which was obviously borrowed from the slide of Sergei Kuzmenko, - compare the two pictures below:
Jokes, jokes, but during the course all students work on their mobile application, and I feel this sticker will be a useful teaching material. It’s time to estimate what I’m already prepared for and what else to think about at each of the development stages.
I have a dream
In the comments to the first article, it was correctly noted: it is important to write a good, detailed brief. From the very beginning of work on the application, you should have some kind of tactics :) At the concept stage, it is important to understand exactly what you are doing and for whom, and what perspective - bright or not - you draw. I recommend to approach the issue of perspective from both sides: the user and the developer.
One of the first documents that you have to create will be a business plan, at first less detailed, but overgrown with more and more nuances: how to pay for the work of the team, what expenses are coming and at the expense of what they cover. For example, I am working on an app for a reward program for interacting with a brand. This is a small side project, and for me the efficiency of financing and team building is especially important. So far my working version is to work out the concept of the application as much as possible and to bow to the commercial director of the company where I work, in the hope that he will see the potential for investment.
In the content of the concept is useful to lay a grocery roadmap and a description of the minimum viable product (Minimum Valuable Product). In program management there is a business case concept similar to our MVP: consider that MVP is a tool that allows you to check at any time whether it is worth going further.
Paws and tail
It seems that only the lazy was not joking at the expense of the Russians, who do not read the instructions for assembling home appliances. But if you are counting on success in creating applications, the documents will have to not only be read, but also written.
Layfkhak: it is completely not obligatory to make long cloths; terms of reference may (and should!) be short, convenient, unambiguous, unambiguous, relevant. The value of this document is strongly tied to time, so you should not make it endless.
Here is an exemplary list of what should be taken into account in the TOR (examples from my application in brackets):
- General description of the subject area (what I mean by the brand engagement reward program and how it works),
- Information model and main entities (consumer, brand, interaction, reward, incentivization),
- Screen map (I don’t give it here, but I’ll keep in mind the list for one or two critical user stories),
- Goals in a simple list (I want to get a certain number of participants who perform such and such target actions),
- Statistics, evaluation, analytics (frequency of calls, session duration, number of interactions, user base dynamics),
- Interaction with other systems (CRM, CMS, DMP),
- Copyright (there is still a lot of work, but I have a small plan based on the same user stories and screens).
Chicken or egg?
An analogue of the well-known dilemma is the question of what to do first, texts or design. The arguments on both sides are iron, and judging by the recommendations of all the speakers of the course (“Do not leave ... at the end”), we will have nothing to do at the end of the application development. My humble opinion: you first need to create a user story, then headlines, then design on flowcharts, then full texts. Of course, the right to use in the design development is not Lorem ipsum, but a substantial text, but it would be an exaggeration to expect that this version of the text will live to a release.
In working on the text, particular attention should be paid to integrity (not to say “consistency”) and key parts of messaging, such as the name or slogan. If possible, write key scenarios yourself or at least get involved in working on them to the fullest.
The second in chronology, but perhaps not the least important step is careful planning of the content. From the very beginning, fix the correct requirements for it (text length, image format, video volumes, etc.) and the volume required for launching. Determine what content you will release, how often and who will be responsible for it. As an illustration, I’ll say that I expect to maximize the content of branded sites in my application, ensuring a constant flow and forming that notorious integrity of communication.
I will not dwell on the design stage. If you want to learn more, look at the piece, written on the basis of the materials of Maria Mikhalchuk , in the last article. Let me just say that it is important to remember that the content is always owned by someone, and some platforms (yes, Mr. Cook?) Watch this especially closely.
Is this anime portal?
For many people, a webmaster, front-end, back-end, full-stack-developers and just “computer scientists” are almost indistinguishable. I think Habr is the last place where you need to tell who of them is doing what. I will allow myself only one advice, referring to the opinion of Sergei Kuzmenko: if you are a product manager and your possibilities are very limited, hire a front-end. Pay special attention to his knowledge of different browsers, mobile OS and the experience of implemented projects. An obligatory skill is also the possession of Photoshop and in general love for exercises with design.
And once again about TK. Make sure that you give the developer a complete description of the tasks, a well-developed design and close to the finished content - then the output is likely to get a testable version of the application.
Tester is a screwdriver with indicator
Returning to the idea that the product should be launched while it is still a little embarrassing for it, I note that the key word here is “a little”. Finding balance remains the most important task for the product manager. Launch alone is not enough, the quality of the product itself must constantly grow.
Here are some test options that are relevant specifically for mobile applications (again in brackets are illustrations for my example):
- Functional testing (performance testing of key scenarios; in my case, this is the display of branded content, personalization, remuneration),
- Research testing (less formal, to a lesser extent tied to test cases; it is useful to use it in the early stages, when not all the documentation is ready, but you can already check the operation of the product). Here is an attempt to speculate on the topic.
- Case plan testing (more formal, classic, with a detailed sequence of actions and expected results; useful when you need to check a detailed user path, made improvements, or if you need to regularly monitor standardized scenarios),
- Compatibility testing (in my case, first of all with updates of mobile platforms),
- Load testing (important for my application, because activations attract very large wavy loads),
- Usability testing (it is still useful to check several versions of the interface if possible).
Relevant and current test plan is a very, very good indicator of project maturity.
And immediately drank
All the above steps will go smoothly if you have a good team. It seems that in terms of lectures there is a separate topic on the recruitment of employees, so to save time, I can only say that now a lot of attention is paid to social relations and the common interests of team members. You have to go through a lot together, so it is important that this path is comfortable. Trite, but shared values, openness and a positive attitude provide a significant share of success in the release of the application.
In conclusion, I will give a short release checklist :
- Register a domain (for yourself)
- Make sure that the hosting is paid in sufficient amount, the required configuration and for a sufficient period of time.
- Get an SSL certificate
- Get your developer accounts in mobile stores in advance,
- Sign up for a github account.
Well, arrange a party if everything goes well :) Next time I will talk in more detail about the internal processes of the product team, about working with mobile stores and try to show my work on the screens and description of the application.
Thanks to Appodeal for the pad and Mark Tenu for the experiment.
Source: https://habr.com/ru/post/316654/
All Articles