So, what the course consisted of, what was in its 24 lessons and why it is useful for the developer, and not just for the future product.
Lesson 1. Product
Was: The essence of the product. Life cycle. Product manager tasks. Product vs project.
Useful:It is extremely important for a developer to know the product he is making. For this they pay more stupidly. Of course, you can pretend to be a teapot. Strictly follow the TK and do nothing beyond what is written in the spec. Wrap up all the client's additional wishes and do not start work until the tech lead writes all the details in the ticket, up to the width of the indents on the UI. But, surprise-surprise, with this approach you will never rise above the Middle developer level. There are programmers who pride themselves on their inability to communicate with the team and the client. There are, of course, exceptions. But if you are not Sheldon Cooper in IT, it is better to turn on empathy and figure out how the product works, who participates in it, what they do, what is important to them and why. In one of the projects, a client began to write with boiling water with happiness, when, on the list of features that needed to be done, I asked about priorities.And then he offered to change them, tk. some tasks were blocked by others. And some were incorrectly worded, which would lead to errors in the business process. And the biggest failure I made was when I did a big refactoring without the client's approval, because our client PM and PM were on vacation. The client refused to pay for it, because it didn't carry business-value to the product.
Lesson 2. Hypotheses
Was: Definition of a hypothesis. Setting goals for SMART. HADI cycles.
Useful: "Who does not know which harbor to sail to, for that there is no tailwind" - said Lucius Annei Seneca, the mentor of Nero, but we love him not at all for this. Hypotheses are about priorities. What to do first, what later, and what never. Priorities affect the speed of the project. Speed ​​- to hit the deadline. Salaries, bonuses and other goodies depend on the deadline for the project. It's like Tetris. There are 20 figures that need to be placed in a glass in a minute. The figures are all different. Their area (the number of squares in each) is known. We summarize the area - they should easily fit close to each other, even the place remains. But ... they don't fit. Because, surprise, they will fit if you put them in the right order. Therefore, an experienced developer does tasks in such an order so as not to slow down the work of colleagues as much as possible. If you need to make a Web API, first agree on the interface and make method stubs so that front-end developers can call the API,and then modifies the body of the methods. If he is engaged in a database, then he starts tables as soon as possible so that they can be used on the back-end, and does views, indexes and other binding later. If he writes a document, he uploads a draft for ASAP review, and does not publish it 5 minutes before the didline, as it seems to him, a 100% perfect document.
Lesson 3. Team management
Was: Team building. Agile. Kanban.
Useful: These are must have skills for programmers and not only. Modern IT products are made by teams. If you don't know how to work in a team - welcome
Lesson 4. Review tasks and project selection
Was: Review of real product problems. Participant case presentations.
Useful: It would seem. Why would a programmer know how they solved the issue of low ad conversion, increase in average check or virality of customer acquisition? Simple answer. Problem solving skills - problem solving skills. This is what recruiters have been praying for for the past 10 years and what is found in every second vacancy in the US / EU. Someone else's experience is never superfluous. After voicing the problem, the lecturer suggested discussing how the course participants would solve it. It is never superfluous to use your brains and learn from other people's experience.
Lesson 5. Product evaluation
Was: Market assessment and competitor analysis.
Useful:Knowledge not obvious to the programmer. Feature list tables, SWOT analysis, TAM / PAM market sizes - why is this? Yes, there seems to be no need until you decide on the choice of a technology stack in the project. Or you think you need to immediately switch to the latest versions of the libraries as soon as they come out (no). Or decide which university to go to. Or in what language to write your first projects. In short, you make a strategic decision that will determine your destiny for years to come. C # or Java? Angular or React? MSSQL or Oracle? App store or Google Play? Native mobapps or QT / Xamarin? Visual studio, WebStorm or Visual studio code? I am still ashamed of the case with one customer. He was looking for contractors to develop a large ERP system from scratch. Our company offered him a team and a stack - Silverlight. For 1.For 5 years we made a product and then Microsoft announced that it was no longer supporting Silverlight. Fatality! The finished, debugged system can be thrown into the trash. The client spent 10 people * 18 months * on the development alone * average monthly payment including taxes, say $ 3,000 = $ 540,000. Half a dog down the tail! And if we add the lost profit, taking into account the development of a new system (the company earns ~ 10 billion euros per year), imagine the damage from the decision. The issue is not only about IT. Blondes or brunettes? Buy an apartment or rent? Live in the city or in the suburbs? Should I vote or go to the country house? Which company to work for? Move to the capital or stay in your hometown?The client spent 10 people * 18 months * on the development alone * average monthly payment including taxes, say $ 3,000 = $ 540,000. Half a dog down the tail! And if we add the lost profit, taking into account the development of a new system (the company earns ~ 10 billion euros per year), imagine the damage from the decision. The issue is not only about IT. Blondes or brunettes? Buy an apartment or rent? Live in the city or in the suburbs? Should I vote or go to the country house? Which company to work for? Move to the capital or stay in your hometown?The client spent 10 people * 18 months * on the development alone * average monthly payment including taxes, say $ 3,000 = $ 540,000. Half a dog down the tail! And if we add the lost profit, taking into account the development of a new system (the company earns ~ 10 billion euros per year), imagine the damage from the decision. The issue is not only about IT. Blondes or brunettes? Buy an apartment or rent? Live in the city or in the suburbs? Should I vote or go to the country house? Which company to work for? Move to the capital or stay in your hometown?Blondes or brunettes? Buy an apartment or rent? Live in the city or in the suburbs? Should I vote or go to the country house? Which company to work for? Move to the capital or stay in your hometown?Blondes or brunettes? Buy an apartment or rent? Live in the city or in the suburbs? Should I vote or go to the country house? Which company to work for? Move to the capital or stay in your hometown?
Lesson 6. Target audience
Was: Methods for describing target audience. Segmentation.
Helpful: I'll reveal a terrible secret. Not a single client in the world pays a programmer just to enjoy watching him bang on the keyboard, google a stackoverflow, drink coffee, discuss the principles of polymorphism with colleagues, and give clever cues at conference calls. The client pays to solve his problems. Therefore, it is worth knowing and respecting your client at least for the fact that he pays you money. Without a client, you just write fun apps for free. Such a cute hobby at home like collecting stamps or burning wood.
Session 7. Client Research
Was: Customer development (customer research through problem interviews).
Helpful: Like the previous lesson was about the client. Why another one? You must Fedya, you must! Here we are talking about an interview. You need to talk to the client. And few people know how to do this. Do not press with your opinions, do not suggest answers, ask about the past, not the future, find out specific numbers, not wishes, clarify uncertainties, have a conversation plan and fix agreements, listen more, talk less. Nothing better than Rob Fitzpatrick's book "Ask Mom" ​​has been written yet. And I even have a review of it. Suddenly, speaking in a castedev format is not only possible with the client, but also with colleagues.
Session 8. Practical interviewing
Was: Search for respondents. Formulation of questions. Customer Development in Practice.
Useful:To become a good interviewer, unfortunately, you also need to conduct interviews. I speak English perfectly, with all the gerunds, I can recognize slang and imitate any accent, I joke incendiaryly and understand the subtlest nuances of the language. But it's in my head. In practice it sounds like this: “Ixcuzmi. Veriz eeee niarest shop? Shop visa products? Chip notes, damn how expensive, but, for sure, expansive! ". Theory doesn't work without practice. A very traumatic experience for the psyche of any hickey programmer is finding interviewees. Get out of the building and other things. It is physically difficult to force yourself to call an unfamiliar company and ask for an interview or offer a service. Or ask about something on the street. But what does not kill makes us stronger. A phone call won't kill you. The main thing is not to call in the rain and not hide under the trees.
Session 9. Qualitative and quantitative research
There were: Interviews, polls, focus groups, experts, webvisor, mystery shopper, A / B tests.
Useful: You need arguments to make a decision. Arguments need facts. Facts are based on numbers. The numbers are derived from research. Different types of research on the same thing give a more realistic picture. Why does a developer need it? We live in a very cruel world. It is no longer possible, as in some seventies, to go to the boss and ask for $ 152 billionfor landing on the moon, cleanly look, although everything is perfectly visible through a telescope. If you propose refactoring, it is better to show the profit from it in numbers. For example, speeding up database queries by X-times, reducing code duplication and speeding up changes or fixes by Y-times. The purchase of a resharper is justified by accelerating the coding by a factor of Z. Free Pizza on Fridays - 100,500+ times better team spirit.
Lesson 10. Generating ideas
Was: Method 6 hats, Walt Disney, stupid cow, reverse generation, focal objects, TRIZ.
Useful: My favorite pastime. As one smart man said, "Programming is an invention on demand." There is nowhere in IT without it. How many times have I faced a seemingly insoluble problem, and after the insight I found an elegant solution. As it turned out, people came up with a bunch of ways to stimulate creativity. A working way is to explain the problem to a colleague, ask for advice and find a couple of alternatives during the discussion. You need to communicate more. It is good to "sleep" with thought and in the morning the subconscious mind finds a solution or to engage in physical activity (swimming) and in the process think about the idea.
Lesson 11. Value Proposition
Was: Compilation of the CPU. Lean Canvas, Value Proposition Canvas.
Helpful: Again, those who are purely technical will be disappointed. Any names of functions, libraries and programming language syntax. None of this, of course, happened. And there was analysis, formulating questions and getting answers, searching for information, drawing up tables and structuring data. Everything without which it is impossible to imagine a good IT specialist.
Lesson 12. Business Models
Was: Types and construction of business models. Business Model Canvas. Product monetization.
Helpful: Similar to the previous lesson on CPU. Wiggling brains at full speed. A useful topic about the types of monetization, because it's always best to imagine exactly how your product makes money.
Lesson 13. Product Roadmap
Was: Roadmap. Gantt chart. Strategy. Release Plan. Product Backlog. Development Backlog.
Useful: This one is more for a tech lead and project manager. Release functionality, didlines and milestones, risks, accounting for available resources, loading people and plans to conquer the world.
Lesson 14. Designing an MVP
Was: Types of MVP (Minimum Viable Product). AIDA and 4U when creating a landing page.
Useful: For product management, MVP is about building a prototype product to test demand quickly and cheaply. How does this relate to development? The fact is that programmers are assigned tasks, but often it is not specified exactly how these tasks should be solved. Therefore, a good developer tries to save resources and make the task with minimal effort, because priorities can change, and nobody canceled the didline. If it is said to make an editable data table, then you should not make a control that will be able to display any types of data, including pivot mode, Excel functionality and data export in any formats. The principles of YAGNI , KISS andthe sin of premature optimization is about that. And never, you hear, never do a task and a big refactoring in one ticket! (crying).
Lesson 15. TOC
Was: Theory of Constraints. Narrow places.
Useful: This is direct TOP when optimizing the speed of the program. For products, it was about optimizing the narrowest part of the funnel. For an IT specialist, it is often necessary to increase the response speed - page load, report generation, file upload. SQL has query plan, caching, and other optimization techniques. It is always worth improving the bottleneck in the system. And for this, you need to measure the stages of the process, log timing and make decisions based on numbers, and not feelings like "I will rewrite from LINQ to storage, it seems to help."
Lesson 16: User Stories and Scenarios
Was: Building and using Customer Journey Map.
Helpful: I confess. Programming is fun, writing documentation is boring. In the middle lies the design of interfaces (UX, not to be confused with UI). It's more fun than boring. Sketch interfaces in Visio, think over usage scenarios, write business rules. If you want to grow from a developer to a lead, PM, analyst, product or architect, it's better to master this technique. I'm not even saying that often the requirements for software are set rather vaguely, or even without UI layouts at all. Therefore, designing a decent interface yourself right away, resolving logical inconsistencies in business logic in a timely manner will greatly save time and affect your satisfaction with your work.
Lesson 17. UX
Was: Scripts. UX basics. Landing page. CJM.
Helpful: There was UX practice here. It turns out that I am behind the times. People have been making web pages for a long time in Tilda , Figma and, God forgive me, Tinkoff . And diagrams and UX prototypes are not made in Visio, but in Google Drawings , Draw.io and LucidChart . For the basics of proper design (indents, visual blocks, fonts, accents) I liked the book by Vlad V. Golovach "User Interface Design: The Art of Washing an Elephant" . The link is the second version, I read the first, it is better.
Lesson 18. Metrics
Was: Key metrics, customization, collection.
Useful: Making decisions based on data is useful. Data is the new black, Data-Driven Decision-Making and all that. In cool IT companies, developers get used to measuring and operating with a bunch of data - the results of running tests, deploying to the server, code quality checks, the progress of closing Tasks in Jira, and so on.
Session 19. Unit Economics
It was: Actually, Unit-economics.
Useful: Super useful theme for products. You have to earn more (3+ times) on the sale of a unit of goods than you spend on the production of the same unit. What is the analogue for developers? I do not know. After all, the programmer is tasked with making the functionality within the scope-time-money-quality square. How much money this or that feature will bring in comparison with the costs of its production is determined by the product and the priorities set by it.
Lesson 20. Analysis of a real product launch case
Was: Product launch methodology. Generation of product improvements.
Useful: Experience is always useful, and experience in a bloody enterprise is doubly useful. There is an opinion that freelancers are not very fond of employing corporations, especially for highly loaded legacy systems. It's not even about the NDA, the inability to work in a team, the inconvenience of remote communication and what other typical problems with outsourcing are there. It's just that there are nuances in a living system that a freelancer may not even think about. From bureaucracy to interoperability of integrations and a convenient time window for deployment. Not to mention the problem of updating the database in real time, API versioning, etc.
Lesson 21. Practice in evaluating product solutions
Was: Mechanics for evaluating product solutions.
Useful:This was a continuation of the previous lesson. Only with a focus on intensive practice, hypothesis generation, task assignment and tracking results. In short, the operating system. It would be helpful for a good developer here to understand that the work will not run away. The tasks that need to be done yesterday come in a couple of pieces a day. One of them will appear at the moment when you leave work and finally check your mail. That work-life balance is important. That there are times when you just need to take it and do it regardless of the time of day. But it is equally important not to get bogged down in a routine and not burn out in a couple of months. That you can stay at work for 4-6 hours above the norm, but this means that the next day labor productivity will be at best 50-70%, so constant overtime is pointless.
Lesson 22. Prioritizing product tasks
Was: Methods MVP - prioritization, ICE / RICE, Binary - prioritization, payback period.
Useful:Good topic because developers constantly have to give estimates of the complexity of tasks. It's not as easy as it sounds. Gradually, you can perk up to make more or less adequate estimates so as not to screw up by more than 20%. But usually PMU doesn't like such numbers. It is difficult because there are interdependent tasks, the factor of familiarity with a specific section of the code and / or technology, pressing the PM to reduce the time, since “He used to be a developer and remembers that it’s simple”, vague speculation (I love it when the analyst adds new points during the development process), the subjective opinion “UI looks OK or needs to be improved”, the desire not to look stupid in comparison with the others and therefore sharply reduce your assessment, pressure from colleagues, a recommendation issued from above “we have already signed an agreement with the client for the exact amount and terms”, etc.
Lesson 23. Preparation for the defense of work
Was: Types of presentations. Tips for speaking. Test runs of reports.
Helpful: Again. If you do not plan to grow above the Middle Developer, skip this point. For the rest, and for their own development, it will not be superfluous to learn how to prepare a report, ignite the audience, not fall over with tricky questions, constructively discuss the topic and defend their point of view or change it without going to extremes of the Criminal Code of the Russian Federation in the form of inflicting grievous bodily harm on ideological opponents ...
Lesson 24. Defense of term papers
It was: Fighting performance in front of an audience.
Helpful: Well, actually, a live performance. You can prepare for a long time, lick the preza, take lessons in public speaking and acting. But after the first blow to the jaw (going on stage), all this flies out of my head. I don’t know why in large IT companies they speak at conferences or at least write articles for specialized publications at least a couple of people. Despite the fact that this greatly improves the ability to formulate thoughts, the speaker's personal brand, develops the IT community, and saves companies on PR and HR costs.
How else can a developer stop being just a coder of UI-forms for accessing a database and become imbued with product thinking?
First, there is a new trend for turquoise organizations . There is an excellent essay on the topic on habr . Of course, many things look a little utopian. Giving responsibility without real power and financial commitment can be very risky. And who is easy now?
Second, or maybe this is the manifesto for the first point - " Funky business ". Selected quotes from the book can be read here. What I love about these lyrics is that they are written as a religious revelation. As blurry as possible, accessible, for all good, against all bad. This is not a disadvantage, but on the contrary, a dignity. Everyone who reads will think and draw their own conclusions.
Finally, there is the recent corporate innovation trend . Hackathons, startup pilots, internal entrepreneurship development, digital transformation strategy, Lean, Customer development and Design Thinking. There is a great schema on the topic from Disruptive.vc :
Conclusion
I am sure I have not revealed any secret. The more you know, the better. Even if there is a lot of knowledge, there are many sorrows. At a restaurant team building with a UK client, our tech lead showed a box of matches trick. He put it on the edge of the table, hit it from below and threw it into the air and with the same hand lit a match against it. The client was so impressed that he paid the bill for the entire team, from beer to sea creeps. And one of the PMs joked so well that stand-ups and retro turned into comedy clubs in the best years. You can even say that the skills of a product manager will not only be superfluous for the developer, but any skills in general play a positive role in the work, the point is only in their correct application . Therefore, let's learn, keep developing and enjoy our work!