Why should a developer know about product management?
So, what the course consisted of, what was in his 24 lessons and why is it 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 that he makes. They stupidly pay more for this. Of course, you can pretend to be a kettle. Strictly follow TK and do nothing beyond what is specified in the spec. Wrap up all additional client’s Wishlist and do not start work until the techlid 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 level of Middle developer. There are programmers who are proud of their inability to communicate with the team and the client. Of course, there are exceptions. But if you are not Sheldon Cooper in IT, it is better to include empathy and figure out how the product works, who is involved in it, what they do, what is important to them and why. In one of the projects, the client began to write boiling water with happiness, when I asked about the priorities on the list of features that need to be done. And then he suggested changing them, because some tasks blocked others. And some were incorrectly formulated, which would cause errors in the business process. And the biggest file I made when I did a lot of refactoring without consulting the client, because Our PM and PM client were on vacation. The client refused to pay for it, because it did not carry a business-value product.
Lesson 2. Hypotheses
Was: Defining a hypothesis. Setting goals for SMART. HADI cycles.
Useful: “Who doesn’t know which harbor he should sail for, there will be no fair wind,” said Lucius Anney Seneca , Nero’s mentor, but we don’t love him at all for that. Hypotheses are about priorities. What to do first, what later, and what never. Priorities affect project speed. Speed - on time. Salaries, bonuses and other buns depend on the timing of the project. It’s like in tetris. There are 20 figures that you need to put in a glass in a minute. The figures are all different. Their area (the number of squares in each) is known. Summarize the area - they should easily fit right next to each other, even the place remains. But... do not fit. Because, surprise, they will fit if they are laid in the correct order. Therefore, an experienced developer does the tasks in this order so as not to hinder the work of colleagues. If you need to make a Web API, you first agree on the interface and stub the methods so that the front-end can call the API, and then refine the body of the methods. If the database is engaged, then it starts tables as soon as possible so that they can be used on the back, and it does the views, indexes and other bindings later. If he writes a document, he puts out a draft for review by ASAP, and does not publish it 5 minutes before the didline, as he thinks, is a 100% perfect document.
Lesson 3. Team Management
It was: Team building. Agile Kanban.
Useful: These are must have skills for programmers and more. Modern IT products are made by teams. If you don’t know how to work in a team, welcome
Lesson 4.Overview of tasks and project selection
It was: Overview of real product challenges. Presentations of cases of participants.
Helpful: It would seem. Why should a programmer know how they solved the issue of low advertising conversion, increasing the average bill or virality of attracting customers? Simple answer. Problem solving skills - problem solving skills. What recruiters pray for the past 10 years and what is found in every second job 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. Turning on your brain and learning from someone else's experience is never superfluous.
Lesson 5. Product Evaluation
Was: Market assessment and competitor analysis.
Useful: Unobvious knowledge for the programmer. Feature tables, SWOT analysis, TAM/PAM market sizes - why is this? Yes, it seems like there is no need so far in the project you do not decide on the choice of the technological stack. Or you think that it is necessary to immediately switch to the latest versions of libraries as soon as they are released (no). Or decide what university to enter. Or in what language to write your first projects. In short, make a strategic decision that will determine your fate 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.5 years, we made the product and then Microsoft announced that it was no longer supporting Silverlight. Fatality! Ready, debugged system can be thrown in the trash. Only on development, the client spent 10 people * 18 months * average monthly payment, including taxes, say $ 3 thousand=$ 540 thousand. Half-lyama dog under the tail! And if you add lost profits, taking into account the development of a new system (a company earns ~ 10 billion euros a year), imagine the damage from the decision. The issue is not just about IT. Blondes or brunettes? Buy an apartment or rent? Living in the city or in the suburbs? Go vote or go to the cottage? Which company to work in? Relocate to the capital or stay in your hometown?
Lesson 6. Target Audience
It was: Methods for describing the target audience. Segmentation.
Useful: I’ll tell you a terrible secret. Not a single client in the world pays a programmer that he simply likes to watch him knocking on the keyboard, google stackflow, drinking coffee, discussing the principles of polymorphism with his colleagues and delivering smart cues for conference calls. The client pays to solve their problems. Therefore, knowing and respecting your client is at least for the fact that he pays you money. Without a client, you just write applications for free for fun. Such a cute home hobby, like collecting stamps or burning on a tree.
Lesson 7. Customer Research
Was: Customer development (customer research through problem interviews).
Useful: It seems that the previous lesson was about the client. Why one more thing? You must Fedya, you must! This is an interview. You need to talk with the client. And few people know how to do it. Do not crush your opinion, do not prompt answers, ask about the past, and not about the future, find out specific numbers and not wishes, clarify uncertainties, have a plan of conversation and fix agreements, listen more, speak less. According to castdev, nothing better than Rob Fitzpatrick’s book “Ask Mom” has not yet been written. And I even have a review for it. Suddenly, you can speak in a casteva format not only with the client, but also with colleagues.
Lesson 8. Interview workshop
Was: Search for respondents. Formulation of questions. Customer Development Practice.
Useful: To become a good interviewer, unfortunately, you also need to conduct an interview. I speak English very well, with all the gerunds, I can recognize slang and imitate any accent, jokingly and understand the subtle nuances of the language. But it’s in the head. In practice, it sounds like this: “Ikskyuzmi. Veriz uh niarest shop? Shop visa products? A chip of notes, damn how expensive, but certainly extensive! ” A theory without practice does not work.An experience that is very traumatic for the psyche of any hickey programmer is finding respondents for interviews. Get out of the building and other things. It’s physically difficult to make yourself feel cold 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 will not kill you. The main thing is not to call during the rain and not to hide under the trees.
Lesson 9. Qualitative and quantitative research
It was: Interviews, surveys, focus groups, experts, webviewer, mystery shopper, A/B tests.
Useful: Arguments are needed to make a decision. Arguments need facts. Facts are based on numbers. The numbers are the result of research. Different types of studies of the same give a more realistic picture. Why does the developer need this? We live in a very cruel world. It is no longer possible, as in some seventies, to go to the chef and ask to allocate $ 152 billion for landing on the moon to cleanly pee, although everything is clearly visible through the telescope. If you offer 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 fixing by Y times. The purchase of the resharper is justified by accelerating coding by a factor of Z. Free pizza on Fridays - 100500+ times better team spirit.
Lesson 10. Generating Ideas
It was: Method of 6 hats, Walt Disney, stupid cow, reverse generation, focal objects, TRIZ.
Helpful: My favorite pastime. As one smart person said: “Programming is an invention on demand.” In IT, there’s nowhere without it. How many times have I encountered a seemingly insoluble problem, and after an insight I found an elegant solution. As it turned out, people came up with a bunch of ways to stimulate creativity. The working method is to explain the problem to a colleague, ask for advice and find a couple of alternatives in the discussion process. Need to communicate more. It’s good to “sleep” with a thought and in the morning the subconscious mind finds a solution or to engage in physical activity (swimming) and in the process reflect on the idea.
Lesson 11. Value proposition
Was: Compiling the CPU. Lean Canvas, Value Proposition Canvas.
Helpful: Once again, fans of purely technical knowledge will be disappointed. Any names of functions, libraries and syntax of a programming language. Of course, none of this happened. And there was analysis, formulating questions and receiving answers, searching for information, compiling tables and structuring data. All that without which it is impossible to imagine a good IT specialist.
Lesson 12. Business Models
It was: Views and building business models. Business Model Canvas. Product Monetization.
Helpful: Similar to the previous lesson about CPU. Stirring the brain at full speed. A useful topic about types of monetization, as It’s always better to imagine 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 likely for techlis and project manager. Functionality of releases, didlines and milestones, risks, accounting of available resources, loading of people and plans to conquer the world.
Lesson 14. MVP Design
Was: Types of MVP (Minimum Viable Product). AIDA and 4U when creating a landing page.
Useful: For product management, the essence of MVP is to prototype a product to test demand quickly and cheaply. How does this relate to development? The fact is that tasks are set for programmers, but it is often not specified how exactly these tasks should be solved. Therefore, a good developer tries to save resources and make the task with minimal effort, because Priorities may change, and nobody canceled the didline. If it is said to make an editable data table, then you should not do a control that will be able to display any kind of data including pivot mode, Excel functionality and uploading data to any formats.Principles YAGNI , KISS and the sin of premature optimization is about that. And never, hear, never do a task and a lot of refactoring in one ticket! (crying).
Lesson 15. TOC
Was: Theory of Constraints. Bottlenecks.
Useful: This is directly 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 - loading a page, generating a report, uploading files. For SQL, there is a 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, rather than sensations like “I’m rewriting from LINQ to the storage, it should help.”
Lesson 16. Custom Stories and Scripts
Was: Building and using the Customer Journey Map.
Helpful: I admit. Programming is fun, writing documentation is boring. In the middle lies the design of interfaces (UX, not to be confused with UI). This is more fun than boring. Sketch interfaces in Visio, think over usage scenarios, write down business rules. If you want to grow from a developer to a lead, PM, analyst, product or architect, it is better to master this technique. I'm not saying that often the software requirements are set rather vague, and even without UI layouts in general. Therefore, designing a decent interface immediately, resolving logical inconsistencies in business logic in a timely manner will save a lot of time and affect your satisfaction with your work.
Lesson 17. UX
Was: Scripts. UX basics. Landing page. CJM.
Helpful: Here was a UX practice. It turns out I am behind the times. Web pages people have long been making up for Tilda , Figma and, God forgive me, Tinkoff . But diagrams and UX prototypes are not made in Visio, but in Google Drawings , Draw.io and LucidChart . For the basics of proper design (indentation, visual blocks, fonts, accents) I liked the book by Vlad V. Golovach "Design user interface: the art of washing an elephant ” . Following the link the second version, I read the first, it is better.
Lesson 18. Metrics
Was: Key metrics, customization, collection.
Helpful: Making data decisions is a good thing. Data is the new black, Data-Driven Decision-Making and all that. In cool IT companies, developers get used to measuring and operating everything with a bunch of data - the results of running tests, deploying to the server, checking the quality of the code, the progress of closing tasas in Jira and others.
Lesson 19. Unit Economics
It was: Actually, Unit-economy.
Useful: A super useful topic for products. You should earn more (by 3+ times) on the sale of a unit of goods than spend on the production of the same unit. What analogue for developers can be given? I do not know. Still, the programmer is tasked with making the functionality fit into the square of scope-time-money-quality. How much this or that feature will bring money in comparison with the costs of its production is determined by the product and the tasks priorities set by it.
Lesson 20. Analysis of a real case of product launch
Was: Product launch methodology. Product Improvement Generation.
Useful: Experience is always useful, and experience in the bloody enterprise is doubly useful. There is an opinion that lone freelancers are not very fond of attracting corporations to work, especially for highly loaded legacy systems.It's not even 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 might not have to think about. From bureaucracy to interoperability integration and a convenient time window for deployment. Not to mention the problem of updating the database in real time, versioning of the API, etc.
Lesson 21. Product Evaluation Practice
Was: The mechanics of evaluating product solutions.
Helpful: This was a continuation of the previous lesson. Only with a bias in intensive practice, generating hypotheses, assigning tasks and tracking results. In short, OSes. For a good developer, it would be useful to understand that work will not run away. The tasks that need to be done yesterday come in a couple of pieces per day. One of them will appear when you leave work and finally check your mail. What is important is the work-life balance. There are times when you just need to take and do it regardless of the time of day. But it is equally important not to wallow in a routine and not to 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 processing is pointless.
Lesson 22. Prioritizing Product Tasks
It was: MVP methods - prioritization, I.C.E/RICE, Binary - prioritization, payback period.
Useful: Good topic, because developers constantly have to evaluate the complexity of tasks. It is not as simple as it seems. Gradually, you can focus on making more or less adequate estimates so as not to screw up more than 20%. But usually these numbers do not like PMU. This is difficult because there are interdependent tasks, the factor of acquaintance with a specific section of the code and/or technology, PMa pressure to reduce the time, because “He used to be a developer and remembers that it’s just”, a blurry spec (I love it when the analyst adds new points during the development process), the subjective opinion “UI looks OK or needs to be finalized”, the desire not to look stupid compared to the rest and therefore abruptly to lower their assessment, by the pressure of colleagues, the recommendation “from the top,” we have already signed an agreement with the client for the exact amount and terms ”, etc.
Lesson 23. Preparing for job defenses
Was: Presentation types. Performance Tips. 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 to fall out of tricky questions, to constructively discuss the topic and defend your point of view or change it without going to extremes of the Criminal Code of the Russian Federation in the form of grievous bodily harm to ideological opponents.
Lesson 24. Protecting Coursework
Was: Fighting in front of an audience.
Helpful: Well, actually, a live performance. You can prepare for a long time, lick the prese, take lessons in oratory and acting. But after the first blow to the jaw (entering the stage), all this flies out of my head. I don’t know why large IT companies speak at conferences or at least write articles in specialized publications on the strength of a couple of people. Despite the fact that it’s great for pumping the ability to formulate thoughts, the speaker’s personal brand is developing the IT community, and companies are saving costs on PR and HR.
How else can a developer stop being just a UI form coder for accessing a database and imbue with product thinking?
Firstly, a new trend for turquoise organizations . An excellent essay on the topic is on the hub . Of course, a lot looks a little utopian. Giving responsibility without real power and financial obligations can be a very risky undertaking. And who is easy now?
Secondly, or maybe it's a manifesto for the first paragraph - " Funky Business ". Selected quotes from the book can be read here . What I love about such texts is that they are written as a religious revelation.As blurry as possible, accessible, for all the good, against all the bad. This is not a disadvantage, but rather a virtue. Everyone who reads will think for a while and draw their own conclusions.
And finally, the recent trend for corporate innovation . Hackathons, startup pilots, internal entrepreneurship development, digital transformation strategy, Lean, Customer development and Design Thinking. There is a great outline on the topic from Disruptive.vc :
I am sure I have not discovered any secret. The more you know, the better. Even if many knowledge - many sorrows. At team building in a restaurant with a client from the UK, our tech team showed focus with a box of matches. He laid 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 of the whole team, from beer to marine reptiles. And one of the PMs joked so cool that stand-ups and retro turned into a gum club in the best years. You can even say that the skills of product manager are not only not will be superfluous for the developer, but any skills in general play a positive role in the work, the matter is only in their the correct application . Therefore, let's learn, do not stop developing and enjoy the work !.