Development team management involves a combination of technical leadership, project management, and the ability to grow and nurture a team. These skills have never been more important, especially with the rise of remote work both across industries and around the world. The ability to delegate decision-making is key to team engagement. Review our inventory of tutorials, interviews, and first-hand accounts of improving the team dynamic.
There is no chance you can avoid all the pitfalls and landmines of the product development process. You will get stuck, you will make mistakes, and you will lose time, money, and (more often than you think!) — hope. There is no silver bullet for it. However, there are tried and true, ground-to-earth ways to mitigate this chaos, decrease the entropy of product design and development, and increase your chances of success. We could address it from our product development perspective only but decided to make this guide truly multifaceted. Thus, offered eight experts to answer four pressing questions about product development. For your convenience, each topic is finalized with summary points and extra tips from the QArea team. Let me introduce our participants: Bruce MasonA Delivery and UK Director in QArea.He has over 30 years of experience in software development, building big teams, and fine-tuning the processes within Banking, Fintech, eCommerce, Travel, and Public Administration domains. Bhargav SathishProduct Manager at Capital One, Co-Founder of Earth Hacks.A Product Manager at Capital One, working on an internal platform called SAGE. A professional with experience in consulting, product management, and project management in the IT, healthcare, and financial services industries. Luc PerardAuthentic, customer-obsessed Business Leader who builds and inspires global, high-impact teams. 20 years of experience gained at the most prestigious Internet of Things (IoT) companies – large multinational corporates & startups which sell hardware, software, digital solutions, and IT services. Vignaraj GadviA Product Manager leading the implementation of an innovative technology platform for product designers and engineers. A recognized savvy leader with strengths in re-engineering delivery processes, defining continuous improvement in processes, presiding over lively brainstorming sessions, and building result-driven teams. Praveen Kumar Reddy PolikaDirector and Digital Product Management at Sol Design.Throughout 15+ yrs career, had the opportunity and privilege of driving inclusive change across Fortune 100 companies across many industries by building/enabling teams to create new products and capabilities. Olexii PavliukHead of Delivery at QAreaStarted as a C# developer more than 15 years ago; Aleksey then shifted his focus to building a solution architecture, where he became a true expert. Today, Aleksey helps developers and clients to create projects for any business needs. Melody ShiueCo-Founder, Director, and Chief Design Officer at BodymappMelody is a product designer by trade and a visionary at heart. Her product design strength lies in stakeholder empathy, root cause deconstruction, and resolving complexity into simple, scalable solutions. Jamie IrwinDirector at Straight Up SearcheCommerce, SEO, and Affiliate marketing experts with over seven years of senior experience in the field. His company focuses on ethical, organic growth and enables agencies and businesses worldwide to achieve success with their online campaigns. Hidden Costs of the Product Development Process There is a great temptation to cut corners when it comes to product development. In fact, it's sometimes considered prestigious, or even a sign of wisdom, when you can boast about being able to trim the fat while helping to bring your product to market. And yet, the reality is that making the right set of trade-offs at the right stage of product development requires in-depth knowledge of what goes into it and what costs. Embrace the hidden costs to make a viable budget, and only then trim it. Hidden Costs of the Product Development Process There is a great temptation to cut corners when it comes to product development. In fact, it's sometimes considered prestigious, or even a sign of wisdom, when you can boast about being able to trim the fat while helping to bring your product to market. And yet, the reality is that making the right set of trade-offs at the right stage of product development requires in-depth knowledge of what goes into it and what costs. Embrace the hidden costs to make a viable budget, and only then trim it. Bruce Mason: There are endless hidden costs in any product and project-related lifecycle, but if I need to narrow it to product development precisely, these will be my picks. Regulatory Costs. You just need to follow changes in regulations and, if you are outsourcing, choose a company with strong domain expertise. Testing: Manual vs. Automated. As your product evolves, manual testing may become an overhead, and you may need to switch to automation. Automation is not cheap, but automating it once correctly is extremely efficient and cost-effective. Bhargav Sathish: There are many costs that I believe companies have top of mind, such as research and development (R&D), quality assurance (QA), and regulatory compliance. However, here are the costs that I think are sometimes underestimated: Intellectual property protection. Get IP protection on anything innovative in the market, but there are a lot of costs with filing for IP protection, maintaining it, and potential legal fees if there are disputes. Customer service and support. Great products can sell themselves. However, loyalty to a product or company can be reinforced by being able to provide the best customer service and support compared to competitors. Praveen Kumar Reddy Polika: As the speed of innovation is increasing with every passing year, it's important to have your product launched at quality within the targeted time to market. Delayed or misaligned decision-making may actually be the biggest hidden cost that can delay the product launch. It's important to have an inclusive decision-making process with a bias for speed throughout the lifecycle. Use digital collaborative tools to enable effective processes. Luc Perard: Half of most developers' time is spent researching rather than building and maintaining software. More than half of their work time is spent unproductively from the standpoint of core business objectives. It leads to missed deadlines, overrun budgets, and product failures. Most developers don't work on new products—not from scratch, anyway. They use existing building blocks (e.g., open-source software [OSS] components) that fit together to create new features/capabilities. So before changing functional software, they must understand the OSS elements comprising the software's inner workings and how they interact and depend upon each other. Failure to do so can open up massive structural vulnerabilities or even break mission-critical enterprise applications. Jamie Irwin: "One hidden cost of product development that companies overlook is the cost of customer support. If customers are not serviced properly, and their expectations are not met, they may switch from your brand to your competitors. In the end, most of the products and services have alternatives." Vignaraj Gadvi: Technical debt — a form of accumulation of technical shortcuts or quick fixes that may be made during the development process to meet deadlines or other goals — saves time in the short term and create problems later. Technical dept comes with additional costs as the product evolves and requires maintenance or updates. Rapid prototyping can help gather feedback and make rapid improvements. However, it can also be costly if it involves frequent redesigns or leads to a product that is not fully tested and ready for market. Short Summary Hidden costs teams and managers tend to forget about in the scope of new product development: Regulatory Costs. There are many; they change, and consist of both direct fees and fines you pay, if you fail to comply. Find an in-house or outsourcing expert proficient in this matter — it is cheaper than playing "hide and seek" with a regulator. They always win. Intellectual property protection. Many companies leave it to a blessed "once we are hit the market" moment, just to discover plagiarism and IP rights violations doesn't give you a leeway. Testing: Manual vs. Automated. You need to know when it is time to automate. Normally, it comes when at least 80% of your product is ready and stable (and not four years later!). High turnover that leads to unproductive development work (up to 50% of the time!). Make sure your developers understand the OSS elements comprising the software inner workings and how they interact and depend upon each other. Delays. Have an inclusive decision-making process with a bias for speed throughout the lifecycle. Quality customer service. A struggle to balance cutting overhead costs without sacrificing customer satisfaction and quality products in the brink of recession is real. Technical Debt. It comes with additional costs as the product evolves and requires maintenance or updates. Main Risks That Lead to Project's Failure A risk is a situation or event that might actualize itself. The risk may not endanger the project directly but later backfire and cripple the results of months, if not years, of work. In many cases, it cannot be avoided because it entails an error or a failure of the management system. Thus, it is fundamental to know its nature to prevent it from happening. Vignaraj Gadvi: Lack of problem understanding. Rather often, the product is designed to solve a symptom rather than the root cause of a problem. Insufficient Resources. It's important for product managers to carefully plan and allocate resources, taking into account potential force majors. Poor product execution. Even if a product has an apparent problem to solve and strong market demand, it can still fail if it is poorly executed. It can be caused by poor project management, lack of quality control, or failure to properly test and validate the product. Bhargav Sathish: As product development can take some time, you need to be thinking about how your product will still be relevant in the market once it's released, and not just at the time of development. For example, while the idea for Bodymapp was born out of COVID lockdowns, our product wasn't released until after the pandemic. So, we ensured throughout development that we were considering what our customer's needs would be in the future and made sure that our product fulfilled those needs. Bruce Mason: Immature organizations often don't have a single person for a product owner role and let subject-matter experts (SMEs) maintain a backlog. Letting subject-matter experts try to agree on what should be delivered first backfires immediately. In the end, all get marked critical; the delivery team is in a frenzy, and SMEs insist on everything being an A-level priority… It is a stalemate. As a representative of an outsourcing provider, I convince clients to choose someone to be in charge. You cannot have 50 priority #1 items when we can deliver from 5 to 10 every corresponding sprint. Sometimes, clients don't have anyone to fit the product owner's requirements or rise to the occasion. In this case, we offer an expert from our side to play this role. As a result, they don't have a vested interest, can do well with priorities, and have domain/tech experience. Short Summary Main product development risks that lead to product failure: Lack of problem understanding. Data-based decision-making should help. Insufficient Resources. No matter how good you plan, add 30% to your budget. Poor product execution. Start testing early; see NPD as a series of loops, not a straight "start-finish" line. Relevance. "Black swan" factors can significantly influence the relevance of your product. Always think about a contingency plan. Letting SMEs run the show instead of appointing/hiring a product owner. If you don't have someone for this role — outsource. Decreasing Uncertainty in NPD The new product development (NPD) process involves many unknowns and variables, making it inherently uncertain. In addition, the process of creating a new product involves a lot of experimentation and iteration, which can make it difficult to predict the outcome. Additionally, new products often require the development of new technologies or the application of existing technologies in new ways, which can add to the uncertainty. Even in-depth research that many see as a Holy Grail of NPD doesn't always help — Market and economic conditions may change unexpectedly, making it difficult to predict the potential success of a new product. Take the pandemics. Therefore, it is important to manage and mitigate uncertainty throughout the process to increase the chances of success. Viggy Gadvi: Build scrappy prototypes. Quickly test and validate ideas without investing a lot of time and resources. Seek early customer feedback. A better understanding of customers' needs and preferences will help you refine your product plan and reduce uncertainty. Pivot if needed. Be flexible and ready to make changes to your product plan based on new information or changing circumstances. This can help you adapt to micro-macroeconomic factors or other external influences that may impact your product. Praveen Kumar Reddy Polika: Uncertainties usually happen when communication is strained. Breakdown of communication happens either when there is ambiguity in individual team members' roles/responsibilities or there is very little transparency/info shared. Roles and responsibilities understanding should come with clear escalation paths when there are disagreements. Democratize information and enable access to data, of course, with the right access controls to help with a better decision-making process. Bhargav Sathish: Assemble a strong, diverse team to cross the hurdles easier. Remember — data is money. Data-driven decisions will reduce risks and uncertainty. Make sure that you have contingency plans in place. Not all data-driven decisions will work out in your favor. By investing time in thinking through the fail-safe and "what-if" decisions, you are removing a bulk of the uncertainty ahead of time. Melody Shiue: Visual tools are important for supporting the new product design and discussing the scope across multidisciplinary teams. Don't neglect to visualize product vision, timeline, technical constraints, resource allocation, cost implications, change impacts, and potential risks. It's also useful to do iterative testing in various use cases before release to production. This is a great way to make small, evidence-based changes to product features to create a more user-friendly product. Short Summary Ways to decrease the uncertainty of new product development: Rapid prototyping and MVP. Outsource to build a scrappy prototype faster and cheaper, get a proof of concept, and test the market earlier. Transparent, strong communication. Democratized information, enabled access to data, and clear roles and responsibilities help to minimize the risks in this pain point. Diversity for better decision-making. A strong, diverse team will cross the hurdles easier and offer more sustainable research ideas and solutions. Visualization. Visualize product vision, timeline, technical constraints, etc. TEST! It will allow you to make evidence-based changes and release a quality, glitch-free product. Red Flags at a Product Design Stage "Red flags" in new product development (NPD) refer to potential issues or warning signs that indicate a product may not be viable or successful. They can indicate that a product may not meet customer needs, may be too costly to produce, or may be subject to legal or regulatory issues. The earlier you identify the red flags, the less time and money you will waste on the later design and development, testing, and launch stages. Olexii Pavliuk: "Both fully aligned vision and too much differentiation in stakeholder vision are red flags. If we all think alike, we are most likely producing something too much on the surface, something anyone can think about. There should be arguments, different versions, pros and cons, and rivalry between SME offers. However, if we can't agree on anything except for "let's do it!" — we have a design intention, not a viable product design in the works." Bhargav Sathish: I would concentrate on the following: Insufficient Market Demand — if the market is not available for a product, how can you justify it? Regulatory and Legal Risk — make sure that you do your due diligence on the risks associated with your product. High Production Costs vs. Potential Market Price Viggy Gadvi: Qualitative feedback over quantitative feedback. It's essential to pay attention to the bias of the feedback you are receiving, as this can impact how you interpret and use the information. Qualitative feedback, based on subjective opinions and experiences, may provide valuable insights into user needs and preferences. Still, it can be harder to quantify and analyze. Quantitative feedback, based on objective data, can be easier to interpret. It's essential to strive for quantitative feedback to evaluate relevance and reliability. Praveen Kumar Reddy Polika: Simplification of the problem statement is a very important part of the designing process, and clearly articulating and aligning the design principles is very important. Analysis paralysis is one of the biggest critical red flags during the design stage. To avoid it, have short feedback cycles to get feedback on the design ideas progressively and use that data to improve upon the design. Short Summary Most common red flags in new product development you can't afford to ignore: Thinking too much alike, or not alike at all. Track how your stakeholders see the product development process and desired results. Make sure you have a strong product owner on your side. Low understanding of legal and regulatory grounds. Can cost you a lot of money and can cost you the entire project. Consult with experts, hire them, or outsource the task to a domain-focus company. Lack of quantitative data. While qualitative feedback is truly valuable, make sure you have enough blunt numbers for truly data-driven decisions. Analysis paralysis. With too little or too much data on the table, decisions will be shallow or will be just delayed. Work with short feedback cycles. In the end, nothing beats the wisdom of the crowd. With eight different product development professionals weighing in on these common issues and concerns, we hope that we provided you with a pretty high level of insight. We each have our areas of professional expertise, but at the end of the day, there's no substitute for experience.
I've heard a lot about Jira not being optimized for QA as, at its core, it is specifically a Project Management solution, and, therefore, it is not about test management. But let's be honest here, Jira feels unnecessarily complicated when you get started with it, regardless of your position or goals. And given it's the go-to standard for organizing and managing software development projects – of which QA is an integral part – you'll barely have a choice in the matter. That being said, Jira can (and should) be optimized in a way that is equally efficient for developing new features, testing, and releasing them. In this article, we talk about the following: Effective use of Jira in software testing. Optimizing Jira the QA workflow. Writing and managing tests in Jira. Additional tools and Jira plugins that can help your QA process. Jira for Development vs. Jira for QA Let's start with the elephant in the room. I've seen a lot of materials stating that Jira is not built with bug tracking in mind and that it is often lacking in "this and that." This statement is true as Jira wasn't built for development, HR, procurement, or marketing specifically. It is a project management system that is designed to help with, well, managing teams. That being said, the teams themselves will use Jira differently. And some may have an arguably simpler time. Developers, for instance, might not need to spend as much time in Jira as QA engineers due to the fact that they don't need to create their tickets daily: They'll be working on a handful of User Stories per Sprint. You, on the other hand, will have to cover these stories with tests. The key to striking a delicate balance where everyone can do their job effectively lies in planning your processes in Jira in a way that considers the interests of everyone on the team. Designing Processes With a Jira QA Workflow in Mind Let's look at a couple of handy tricks and process improvements that can not only help QA engineers be more effective but improve everyone's work on a software development project. Include Testers When You Estimate QA Tasks QA engineers aren't typically responsible for providing estimates. However, this can be a good practice as they have much more hands-on experience and can deliver more accurate estimates for QA tasks. Allow Testers to Help Set Bug Priorities As a rule of thumb, QA engineers are quite good at prioritizing bugs thanks to their user experience testing background. Obviously, a project manager can change these priorities based on business needs, but it is beneficial to allow testers to set initial bug priorities. As a tester, you need to consider the following factors when prioritizing a bug in Jira: How often does it occur? What is the severity (how much does it impact the user)? Is the issue blocking the main functionality or some other features? What devices/browsers does the bug happen in? Is the bug impacting the users in a way where they churn or leave negative reviews (have similar bugs caused it before)? For how long has the bug been happening (death by a thousand papercuts is still a thing)? What other features are also coming in this sprint, and what are their priorities? Design Your Board to be More Process-Friendly The iconic Kanban board is probably the first thing that pops into one's head when thinking about Jira. And if you've worked on several projects, you've probably seen them arranged in a variety of ways. The general approach sorts your issues into several columns that move from "to do" to "in progress" and then to "done." That being said, you are not limited to a specific number of columns. Use this to your advantage. I'd suggest having more columns that can clearly illustrate the path your issue needs to go through before it can be considered done. I'd consider having the following columns: TO DO Ready for development In progress Ready for review Ready for testing In testing Reopened Ready for release Released Having a separate column for every stage may seem overwhelming, but only at first glance. In reality, this array gives everyone a nice high-level view and becomes an asset for the QA team. QA-Relevant Issue Fields QA engineers don't typically need too many extra bells and whistles when it comes to issuing fields. In fact, testers will mostly need the default ones with a handful of minor exceptions. However, these tiny changes can make a world of difference in the long run. Here's an example of issue fields I find to be useful in a QA ticket. Summary: This field will have a short – usually one-line max summary of the main problem. Description: This section will be the home to your pre-requisites (if needed), expected and actual results, steps to reproduce, device details, app version, and environment info (unless you have specific fields for this information), and generally any other delta that could help with reproducing the issue withoutasking QA for additional help. Issue type: This field is typically assigned by the Project Manager. They will decide whether an issue is a Story or something else. That being said, you need to ensure that your QAs have the option to create bug report tickets on their own. Assignee: Self-explanatory. Priority: This field is where either the Project Manager or QA engineers themselves set the priority of a bug. Labels: People often overlook this field. However, I find it to be an exceptionally good way of grouping tickets together. Environment: This field can add a lot of necessary details, like whether the feature is in dev or staging. You can also specify hardware and software, like using Safari on an iPad Mini. Affects Version and Fix Version fields: These fields can also add a bit more context by clearly stating the software version. This is handy because the QA engineer can easily understand the version of the app/software that should be used for testing. Components field: This field can come in handy when you need to specify if the product consists of multiple components. Attachment field: You can use this field to add screenshots with errors, log files, or even video recordings of an issue. Linked Issues: This field will help you link bugs to stories or Epics for feature implementation if you know that there's a relation. Due date: This field is useful for general awareness and understanding of when the issue is planned to be fixed. Do note, however, that this field should not be filed by QAs. Please keep in mind that this suggested list of fields is what I consider good to have, but they are not a hard requirement. If you feel comfortable that your process can skip some fields and simply hold more info in the description – go for it. The same can be said about making more fields. Yes, it may seem tempting to formalize everything possible, but you shouldn't go too far. The more fields there are – the more time you'll spend on filling them. This is even more true given the nature of the QA process, as you may need to create dozens at a time. Cultivate the Right Comments Culture Comments in tickets can be a gold mine for a QA engineer as detailed and specific notes will help discover a lot about the feature. They can also become a rabbit hole of irrelevant fluff, as reading through dozens of them will take away precious time that could have been better spent elsewhere. Jira is not Slack, nor should it ever become a messenger. Therefore it's best that your team uses tools that are meant for communication to discuss most details and questions and put the finalized requirements or needed context into tickets. Tags Whenever you are adding any details that should be relevant to a certain developer – tag them. Obviously, the same is true for engineers and managers who want a QA person to look at something specific. Pro tip: You can use a checklist plugin to break down tasks into actionable items. Smart Checklist will allow you to add custom statuses, tag users, and set up deadlines for each item individually. Sub-Tasks Many testing teams use sub-tasks for bugs that are related to a feature ticket. This approach usually narrows down to either personal preference or the culture a team has developed. And it makes a lot of sense, at least on paper. That being said, I'd advise against it as sub-tasks are not clearly visible on the board, making it harder for the manager to review progress. Another reason for using separate tickets for bugs is that sometimes a decision can be made to release a feature despite it having some bugs, in which case, they'd really love the ability to move it to done. A workaround would be to create separate issues and link them together. This way, you'll still see the feature a bug is linked to without negatively affecting the board's visibility. Backlog Grooming A typical backlog consists of dozens of tickets with a "medium" or lower priority. If uncared for, it will eventually become a black hole that hoards copious amounts of tickets that never see the light again. But have you ever heard of the straw that broke the camel's back? People who continuously experience minor bugs and inconveniences will eventually shift to a more stable solution. Therefore you need to ensure that at least some of the tickets from the backlog are continuously making their way into the sprint. Some of the best practices I'd recommend to make sure that the minor bugs don't become a major issue are: Periodically having Sprints that are dedicated to lower-priority issues. Committing to pulling a certain number (it doesn't have to be a large number) of tickets from the backlog into every sprint. Sprint Lag for Automation Covering a feature that's still in progress with automated tests can lead to a lot of unnecessary work as things may (and probably will) change. That's why having your Automator lag one sprint behind so they can cover a completed feature with scripts is actually a nice practice. The fact that the tickets were already covered with test cases is also a boon, as they will add even more context. You'll have to properly label these kinds of tickets to avoid confusion. How to Write Tests in Jira? We need to understand what tests are before we are able to write and execute them properly. Luckily, the concept is quite far from rocket science. Your typical test will be comprised of three parts: The scenario: This is the basic idea of a test and is used to indicate what you are trying to validate. An example could be making sure a user can only log in using valid credentials. Expected result: An expected result is the behavior you'd expect from a feature when it is working correctly. Think of it as the requirement for success. Validation: This is the description of the method you'll be using to test the feature against the requirements. Following these basic principles will help you write, document, and execute excellent tests. As for using them in Jira specifically, here's what you should do. Indicate that the issue is a Test Case in the title. Example: Test Case: Login functionality. Mention the necessary details in the description: Share the test steps you will be taking, like accessing the login interface and entering valid and/or invalid credentials. Share expected results in the description as well. Creating test cases in Jira can be a tedious and repetitive task, but it is an essential step in ensuring the quality and functionality of a product. A well-written test case can save time and budget in the long run. Consider following these tips to write kick-ass test cases. Start by clearly describing the purpose of the feature and its benefits to the user. This goes beyond just stating what the feature does and should also explain why it is important to have. Define the user interactions and activities required to achieve the desired outcome. This will help ensure that all necessary steps are covered in the testing process. Specify the framework and methodology of the test cases, including any relevant tools or techniques that will be used. Use detailed steps that illustrate what to do, where to navigate, which button to click, etc. This helps the team understand and follow the test case. Prioritize the test cases based on their importance and relevance to the project. This will help in forming the scope for smoke and regression testing. Always link the test cases to the requirements in Jira to ensure that the testing process is aligned with the product's specifications. This will also help in identifying any dependencies between the functionality being tested. Group the test cases based on the product components or user personas and use labels to categorize them. This will make it easier to manage and search for specific test cases in the future. Include variations in the test cases by testing the product under different scenarios and conditions. This will help ensure that the product works as intended in all possible situations. Take advantage of additional tools and functionality available in the Atlassian Marketplace to enhance the testing experience within Jira. How to Manage Tests in Jira? Generally speaking, there are two schools of thought when it comes to managing tests in Jira. One is pretty straightforward and relies on using the functionality that's available in Jira out of the box. The other advocates for using external products like the add-ons that are available on the Atlassian Marketplace. Xray is probably the most well-known add-on for testing; hence I'll be using it for my examples. But for now, let's focus on option number one – vanilla Jira. Using Sub-Tasks As I mentioned above, you can use sub-tasks for tests, but this option has a series of drawbacks and limitations. Therefore, I'd suggest adding an additional issue type to your Jira instance for test cases. This approach will allow you to use sub-tasks more effectively (yes, you'll need to make custom sub-tasks for this to work), as they'll be attached to a specific test case issue. And you'll be using them for submitting the results of your tests. For this, you'll need to open the global settings of your Jira instance and choose the option of the issue from the drop-down menu. From there, you'll need to click on the create button and add your custom tasks and sub-tasks. Then you will need to go to schemes to add your newly created issue type. Simply drag it into the column on the left. Connect the newly created issue type with the test case results in the Jira subtask and use them for your QA purposes. The benefits of this approach are: This method is workable, not necessarily too hard to configure, and it will not cost you any additional funds. On the downside, this can not resolve the challenges associated with reusing test cases, and there's barely any support for exploratory testing or test automation. Using Plugins Then there's the option for using additional add-ons from the marketplace like the aforementioned Xray. Xray is a testing tool that supports the entire testing process, including planning, designing, execution, and reporting. To facilitate this process, Xray uses specific issue types within Jira. During each phase of testing, you can use the following issue types: Plan Phase: Test plan issues are used to create and manage test plans. Design Phase: Precondition and test issue types are used to define the testing specifications. Test sets can be used to organize the tests. Execute Phase: Test execution issues are used to execute tests and track their results. Report Phase: Test execution issues are used to generate built-in requirement coverage reports. Custom issues can also be created using Jira Software tools to create additional reports. If you are new to Xray, it is recommended to start with a small project and use test issues to create and execute tests for your requirements in an ad hoc, unplanned manner. The pros and cons of this approach are literally the reverses of using the default functionality of Jira – you will be able to do more in less time; however, the added comfort will cost you. Using Checklists As I mentioned, there are two "conventional" ways of managing tests in Jira. However, there are some that are less common, and they typically involve certain combinations of the two. Checklists are a great example of an unconventional way of managing tests. Smart Checklist for Jira, for instance, allows you to add checklists to your issues. The built-in Markdown editor simplifies your workflow as you can type or even copy-paste your tests. You can use the formatting options to your advantage when writing tests. For example, you can use headers for test topic values, checklist items for test case values, and details to store your expected results. This way, your tests will have actionable statuses, and deadline and assignee functionality, all while being attached to the parent ticket. Conclusion Jira may seem overwhelming at first glance, but from complexity comes configurability and flexibility. You are free to mold the software in a way that fits your processes, resulting in more productivity inside a unified hub every team in your company uses.
Continuous learning is one of the guiding principles that all people should apply in their life. Reading is an excellent tool to learn, and it is a habit that we should all be doing on a regular basis. Since I love reading books about different topics, in this article, I'm going to share five books that have helped me a lot to improve as Engineering Manager. When we read a book, we should always remember three important things: Authors are sharing their knowledge, thoughts, or experiences based on their context or culture. These factors may be different from ours. The same book provides different values and learnings to each reader for the same reasons. Each reader has a different context, culture, habits, and previous knowledge. Books and methodologies provide guidance that helps us to improve, but they are not our owners. We must take what makes us better, adapt what does not fit, and especially think for ourselves in order to make decisions based on our context. Now let's go to the books that have helped me to better myself. Five Books That Have Helped Me Become a Better Manager The Manager's Path This is my favorite book about engineering management. In my opinion, it provides a clear vision of the Engineering Manager's roles. In my case, it reinforces some of my ideas and provides valuable information about some aspects that needed to be improved, such as 1-2-1 and performance reviews. The following topics were addressed: 1-2-1 and performance reviews Continuous feedback Mentoring How to manage people in different scenarios How to manage a team Managing managers If you are or want to be an Engineering Manager, you can't miss this book. The Goal: A Process of Ongoing Improvement This is a book written in 1992 that is about the optimization of production in a manufacturing factory. It is a great book that gives us a vision of how to manage and optimize a company based on the theory of constraints and work in progress (WIP). It is a book written in a novel format that provides you with knowledge through a suspense story. There is another book based on this that is focused on an IT department, The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win. I like these books because they project a journey in which they describe emerging issues, new challenges, and complex situations closer to the reality of what will be your career as an Engineering Manager. Team Topologies: Organizing Business and Technology Teams for Fast Flow It focuses on how to set up a dynamic team structure and interaction modes that can help teams adapt quickly to new conditions and achieve fast and safe software delivery. It provides valuable and clear information for understanding an IT structure and its interaction. Some of the points he describes you will already know, but it will help you to understand them better: Conway's Law with practical examples Three different organizational structures in every organization: Formal, informal, and value creation Four fundamental team topologies: Stream-aligned, Enabling, Complicated-subsystem, and platform The Obstacle Is the Way: The Timeless Art of Turning Trials into Triumph It is a book based on stoicism. Engineering Managers usually feel a lot of frustration generated by the management of uncertainty, emerging jobs, and multiple obstacles that appear in their day-to-day work. Sometimes we are more focused on what we cannot control and a misperception of situations. This book helps us to focus on the things we can control, let go of everything else, and turn every new obstacle into an opportunity, handle defeat and difficulty. We will learn how to deal with obstacles and how to react appropriately so that they do not hold us back. The Software Architect Elevator: Transforming Enterprises with Technology and Business Architecture It is a book that I recommend for both architectural and management roles. These two roles have many things in common. This book helps us to understand that a company is like a building with several floors, in which, on each floor, there are people speaking different languages and probably going in different directions. We will hear how an architect should ride an elevator up and down to talk with people on different floors to align them to go in one direction. Supporting the business strategy, connecting the dots, and avoiding over-engineering. This ability to communicate at different levels, simplification capacity, and alignment are capabilities that Engineering Managers must also have. What about technical books? Conclusion To support our teams to achieve their objectives, we must have knowledge of different areas and also understand the context of the company. These books provide information on five key aspects: people management, IT structures, company and process optimization, communication at different levels, and how to make a journey full of obstacles.
TL; DR: The ChatGPT Product Owner Job Interview A few weeks ago, I ran a simulated job interview with ChatGPT for a fictitious Scrum Master position. Admittedly, I would not have invited this “interviewee” for an interview with other team members; however, the interview produced some remarkable answers. Consequently, I tried the same with a Product Owner position, aware of the challenges this would pose, as the Product Owner role is significantly fuzzier than the one of a Scrum Master. So, I took a few questions from the "Hiring: 82 Scrum Product Owner Interview Questions" guide and ran a ChatGPT Product Owner job interview. Read on and learn whether a statistical model will challenge product people in the near future. Interviewing ChatGPT The task for this ChatGPT Product Owner job interview session was to create a screening interview of about 30 minutes to decide whether to proceed with a fictitious application for a Product Owner position by ChatGPT. All questions are from the "Hiring: 82 Scrum Product Owner Interview Questions" guide, including guidance on suitable answers. (For example, “Q 03” refers to the third question of the guide.) I ran the ChatGPT Product Owner job interview on 2023-02-14, from 1:30 to 3:45 p.m. CET, on ChatGPT’s February 13 version. I did not edit ChatGPT’s answers. However, on several occasions, I provided feedback to ChatGPT and had it regenerate the previous response to explore how to improve an answer’s quality. Also, I used follow-up questions to explore the model when ChatGPT did not provide obvious answers. The ChatGPT Job Interview for a Product Owner Position Initial Prompt of the ChatGPT Product Owner Job Interview I used the following initial prompt to start the ChatGPT Product Owner job interview: I want you to act as a professional product manager and Product Owner. You are well familiar with Scrum and other agile product development practices. You are applying for a vacant position as Product Owner in an organization that has practicing Scrum well for years. In that organization, the role of the Product Owner is respected, as outlined in the Scrum Guide. Use your knowledge of Scrum, product management, project management, product ownership, product vision, product strategy, product discovery, stakeholder management, communication, alignment, and collaboration principles to answer the following questions of the interviewer. You want to get the vacant Product Owner position! ChatGPT Product Owner Job Interview: The Opening Question Question: Thank you for your application as a Product Owner! Why would you be a good fit for the position? ChatGPT: Thank you for considering me for the Product Owner position. I believe I would be a good fit for this role because I possess the necessary skills and experience required to successfully manage and deliver valuable products in an Agile environment. My background in product management and expertise in Agile methodologies, particularly Scrum, enable me to collaborate effectively with cross-functional teams to define and deliver high-quality products that align with the organization’s strategic goals. I am skilled in stakeholder management, communication, and product discovery, which are essential elements of the Product Owner role. I understand that as a Product Owner, my primary responsibility is to create and communicate a clear product vision, prioritize and manage the product backlog, and ensure alignment with stakeholders. I am committed to staying up-to-date with the latest industry trends, technologies, and best practices to continuously improve product strategy and drive business outcomes. Overall, my ability to lead cross-functional teams, prioritize tasks and requirements, and ensure alignment with stakeholders makes me a great fit for this Product Owner position. Comment: Mentioning “Agile methodologies” and “best practices” as phrases while not noting the Product Goal and customer value make the answer a little better than parroting the prompt with a bit of product management speak thrown into the mix. Also, “[leading] cross-functional teams, [prioritizing] tasks and requirements” does not leave the impression that ChatGPT has a good understanding of the Product Owner position. (I provided my comment as “not helpful” feedback to the answer and had ChatGPT regenerate the answer.) ChatGPT’s regenerated response: Thank you for considering me for the Product Owner position. I believe I would be a good fit for this role because I have extensive experience in product management, including working in agile environments using Scrum. As a Product Owner, my focus is on maximizing the value of the product for both the customer and the organization, while ensuring alignment with the overall product strategy and vision. I am also skilled in stakeholder management and communication, which are critical for ensuring that everyone involved in the product development process is informed and aligned. Additionally, I have a strong background in product discovery, which involves identifying customer needs, validating product ideas, and conducting experiments to inform product development decisions. Finally, I value collaboration and teamwork and believe in creating a supportive environment where the development team can thrive and achieve their best work. Comment: Much better. Please note that ChatGPT considers your feedback as iteration on the original prompt. Q 01: Why Become Agile? Question: What is the purpose of being agile in the first place? Background: As the “Manifesto for Agile Software Development” states, it is mainly about adaptability over following a plan. You want to learn faster than the competition and turn this advantage into marketable products and services, thus contributing to the organization’s sustainability. Practically, being agile is about postponing deciding to make a product investment to the latest economically feasible moment. This is achieved by testing hypotheses as fast and inexpensively as possible, thus mitigating risk and maximizing the value of the Developers’ work. It also means having the courage to stop an effort if the chosen course is no longer viable, feasible, valuable, or desirable. ChatGPT: The purpose of being agile in the first place is to be able to quickly respond to change and uncertainty in the market, technology, or the needs of the customer. The goal of agility is to deliver value to the customer in small increments through frequent and continuous delivery of working software or products, and to do so with high quality and predictability. Agile practices, such as Scrum, Kanban, or XP, provide a framework for product development that emphasizes collaboration, transparency, and flexibility. By being agile, organizations can reduce risk, increase efficiency, and create a culture of continuous improvement that enables them to stay ahead of the competition and adapt to changing market conditions. Comment: I would accept that one! Q 02: Product Owner Role Question: How would you characterize your role as a Product Owner? Are you a facilitator, a coach, a manager, a visionary, a tactician, a coordinator, or a “driver?” Background: This open-ended question serves to understand the candidate’s perception of their role. For example, a Product Owner is in a leadership role; however, yielding no authority in a traditional management sense. Therefore, the Product Owner is featured a bit in all the labels mentioned in the question. The Product Owner role has also been dubbed as the “bottleneck” or the “Achilles heel of the Scrum process;” any mentioning of that would undoubtedly be a plus. If a candidate mainly refers to something like “I am the one creating the user stories,” I would dig into that. ChatGPT: As a Product Owner, I would characterize my role as a combination of facilitator, coach, visionary, and tactician. Facilitator: My role as a facilitator involves creating a collaborative environment where the development team can work effectively, providing guidance on how to use the product backlog, and ensuring that the team has the information they need to build the right product. Coach: As a coach, I help the development team to understand the product vision, strategy, and objectives, and guide them on how to prioritize and refine the product backlog, ensuring that they are building the right features that meet the needs of the customer. Visionary: As a visionary, I have a clear understanding of the product vision, and I communicate this vision to the development team and stakeholders, ensuring alignment with the product strategy. Tactician: As a tactician, I am responsible for creating and refining the product backlog, ensuring that it is actionable, testable, and meets the Definition of Ready. I work closely with the development team to make trade-offs and prioritize features based on customer value, business goals, and technical feasibility. Overall, my role as a Product Owner is to maximize the value of the product for both the customer and the organization, while ensuring alignment with the product vision, strategy, and objectives, and working collaboratively with the development team to deliver high-quality products on time and on budget. Comment: I doubt that ChatGPT knows the 2020 Scrum Guide, as it still refers to the Development Team and ignores the Product Goal. Also, while I appreciate the level of inclusion of the Developers in the “Coach” paragraph, it is the Product Owner who prioritizes the Product Backlog. However, ChatGPT contradicts itself, when the “Tactician” paragraph refers to the Product Owner refining the Product Backlog which needs to meet the Definition of Ready; as we know, there is no Definition of Ready in the Scrum Guide. (I provided my comment as “not helpful” feedback to the answer and had ChatGPT regenerate the answer.) Regenerated ChatGPT response: As a Product Owner, my role is multifaceted and can encompass elements of being a facilitator, coach, manager, visionary, tactician, coordinator, and “driver.” Ultimately, my primary responsibility is to represent the customer and ensure that the development team is delivering value to them by creating a high-quality product that meets their needs. To accomplish this, I work closely with the development team to understand their capabilities, identify priorities, and create a product backlog that aligns with the overall product strategy and vision. I collaborate with stakeholders to gather feedback, build consensus, and manage expectations. I also continuously monitor market trends, competitive pressures, and customer needs to ensure that the product remains relevant and valuable over time. As a facilitator and coach, I help to foster a culture of collaboration, teamwork, and continuous improvement. I provide guidance and support to the development team and help to remove any obstacles that are hindering their progress. I also work closely with the Scrum Master to ensure that the team is adhering to agile best practices and following the Scrum framework. Overall, my role as a Product Owner is to be a servant leader who works to create a shared understanding of the product vision, to prioritize and sequence the product backlog, and to enable the development team to deliver a high-quality product that meets the needs of the customer. Comment: That is an improvement over the first version; the ChatGPT Product Owner job interview picks up speed. (“Driver,” development team, and best practices, however, lower the grade.) Q 16: Product Discovery Question: How would you include your teammates in the product discovery process? Background: Lean UX, Lean Startup, Design Thinking, Design Sprints, or Service Design are other agile practices that might fill Scrum’s void regarding product discovery. (Scrum cannot conceal its tactical focus on product delivery in that respect.) All that Scrum refers to regarding product discovery is that the Product Owner is accountable for managing the Product Backlog. Supposedly, the Product Owner is the individual who knows what is valuable at any given time. But Scrum doesn’t elaborate on how the Product Owner gains this insight. ChatGPT: Including my teammates in the product discovery process is crucial for creating a shared understanding of customer needs, identifying new opportunities, and generating innovative ideas. Here are some ways I would involve my teammates in the product discovery process: Hold collaborative brainstorming sessions: I would organize collaborative brainstorming sessions with the development team to generate ideas and explore potential solutions. By leveraging the collective intelligence of the team, we can identify new opportunities and validate assumptions. Conduct user research together: I would invite the development team to participate in user research activities, such as customer interviews or user testing, to help them gain a deeper understanding of customer needs and pain points. This shared understanding can help the team develop a better product that meets the needs of the customer. Run experiments: I would involve the development team in designing and running experiments to validate assumptions and test hypotheses. This can help us to quickly learn what works and what doesn’t work and make more informed product decisions. Collaborate on product backlog prioritization: I would work collaboratively with the development team to prioritize and sequence the product backlog based on customer needs, technical feasibility, and business value. This can help ensure that the team is working on the most important features that will deliver the most value to the customer. Overall, involving my teammates in the product discovery process can help us to build a better product that meets the needs of the customer and the business, while also creating a sense of ownership and shared responsibility within the team. Comment: Except for ChatGPT’s obsession with the “development team,” it is a good answer. Follow-up question: Are there any particular practices that you would employ for collaborative product discovery? For example, you mentioned user research and running experiments. ChatGPT: Yes, there are several collaborative product discovery practices that I would employ, including: User research: By conducting user research together, we can better understand the customer’s needs, pain points, and behaviors. This shared understanding can help us identify opportunities and generate ideas that better address customer needs. Story mapping: Story mapping is a collaborative technique that involves creating a visual representation of the customer journey and the product features needed to support it. By creating a story map together, we can identify gaps in the customer journey, opportunities for improvement, and dependencies between features. Design thinking workshops: Design thinking workshops are collaborative sessions that use design thinking techniques to generate ideas and prototypes. By working together, we can generate a range of ideas and quickly iterate on them to identify the best solutions. Experimentation: Running experiments together can help us test assumptions and validate ideas. By involving the development team in designing and running experiments, we can quickly learn what works and what doesn’t, and use that feedback to inform product decisions. Retrospectives: Retrospectives are regular meetings where the team reflects on what is working well and what can be improved. By involving the team in retrospectives, we can identify opportunities to improve the product discovery process, and ensure that we are continuously learning and improving. Overall, collaborative product discovery practices can help us to build a better product, create a sense of ownership and shared responsibility within the team, and foster a culture of continuous improvement. Comment: Retrospectives are a core part of a Scrum team’s way of working and are not product discovery specific. On the plus side, ChatGPT mentions user story mapping and Design Thinking. (I provided my comment as “not helpful” feedback to the answer and had ChatGPT regenerate the answer.) Regenerated ChatGPT response: Yes, there are several practices that I would employ for collaborative product discovery, in addition to user research and running experiments: Design thinking workshops: I would facilitate design thinking workshops with the development team, where we could explore customer needs, generate ideas, and prototype potential solutions. This approach can help us to gain a deep understanding of customer needs, and also to generate creative and innovative ideas. Story mapping: I would use story mapping to collaboratively explore and map out the customer journey, from the initial problem or need to the final solution. This can help the team to gain a shared understanding of the customer’s context and needs, and also to identify key features and components of the product. Customer feedback loops: I would establish feedback loops to gather and incorporate feedback from customers throughout the product development process. This can help us to validate assumptions, identify new opportunities, and ensure that the product meets the needs of the customer. Cross-functional collaboration: I would encourage cross-functional collaboration among the development team, stakeholders, and other teams within the organization, such as marketing or customer support. This can help to foster a culture of collaboration and shared ownership, and also to ensure that the product aligns with the overall business strategy. Overall, these practices can help to create a collaborative and iterative approach to product discovery, where the development team, stakeholders, and customers work together to build a product that meets their needs and delivers value. Comment: Lo and behold — given the appropriate prompts, you can lead ChatGPT onto a promising path. Now, we are talking about Design Thinking, user story mapping at the team level, and including customers, stakeholders, and shared understanding and ownership in the process. ChatGPT attempts to maximize the chance that the outcome of the Scrum team’s work will solve the customers’ problems and align with the organization’s overall strategy. I am becoming more optimistic about this ChatGPT Product Owner job interview. Q 28: Uncooperative Stakeholders Question: How do you communicate with uncooperative stakeholders? Background: An often promising way to deal with uncooperative stakeholders is to win them over by demonstrating the value of agile product development. Early in the transition process, educating them with product-related workshops on agile principles is advisable. Proven examples are user story mapping or product roadmap planning workshops. (I recommend securing the help of an experienced coach at this stage.) It has also proven to help establish a close communication schedule with the stakeholders, for example, by having regular meetings. Also, educating members from stakeholder teams to act as “liaison officers” to the product organization significantly improves cooperation. It mitigates the usual feeling of losing control on the stakeholders’ side. At a later stage, typical events, such as Sprint Reviews, also work well by demonstrating what value the Scrum Team created for them. Generally, it is a process that will take time, and no shortcuts are available. As a last resort, if everything else hasn’t worked out, the PO might need support from a C-level sponsor. ChatGPT: Communicating with uncooperative stakeholders can be challenging, but there are several strategies that I would employ to try to improve the situation: Identify the root cause: I would try to identify the underlying reasons why the stakeholder is uncooperative. Perhaps they have a different perspective or agenda, or they are not fully informed about the product or project. Understanding their perspective can help me to find a way to address their concerns. Actively listen: I would actively listen to the stakeholder and try to understand their concerns and perspective. This can help me to build empathy and find common ground, and also to identify potential solutions. Focus on shared goals: I would try to find shared goals and objectives that we can both agree on. This can help to build a sense of alignment and collaboration, and also to find a way forward that benefits everyone. Be transparent and honest: I would be transparent and honest in my communication with the stakeholder, even if it means delivering difficult news. This can help to build trust and credibility, and also to foster a more productive working relationship. Involve senior leadership: If the stakeholder is still uncooperative, despite my best efforts, I would involve senior leadership in the communication process. This can help to address any underlying issues, and also to find a way to move forward. Ultimately, my goal would be to build a productive and collaborative working relationship with the stakeholder, where we can work together to achieve shared goals and objectives. Comment: Principally, these are good answers. However, I would like to learn more about how Scrum can help with this challenge. Follow-up question: Could you rephrase your answer, considering the Scrum framework more? ChatGPT: Certainly! In the Scrum framework, the Product Owner has the responsibility of managing stakeholder relationships and ensuring that the development team has a clear understanding of the product vision and goals. Communicating with uncooperative stakeholders is a key part of this responsibility, and the following strategies can be useful in this context: Identify the root cause: By understanding the stakeholder’s perspective and motivations, the Product Owner can identify the root cause of their uncooperative behavior. This can help the Product Owner find a way to address their concerns and work collaboratively towards the project’s goals. Actively listen: The Product Owner should actively listen to the stakeholder and demonstrate empathy and understanding. By actively listening, the Product Owner can build a better rapport with the stakeholder, and find common ground for collaboration. Focus on shared goals: The Product Owner should find shared goals and objectives that the development team and stakeholders can both agree on. This can help to build alignment and trust, and enable the team to work collaboratively towards a shared vision. Be transparent and honest: The Product Owner should be transparent and honest in their communication with the stakeholder, even if it means delivering difficult news. This can help to build trust and credibility, and foster a more productive working relationship. Involve the Scrum Master: If the stakeholder is still uncooperative, the Product Owner can involve the Scrum Master to help manage the relationship. The Scrum Master can help facilitate communication, find ways to address any underlying issues, and keep the project on track. In summary, the Product Owner should take a proactive approach to managing stakeholder relationships and use effective communication strategies to promote collaboration and shared goals. By doing so, the Product Owner can help ensure the success of the project and the satisfaction of all stakeholders. Comment: Again, this answer is a mixed bag. ChatGTP refers to “shared goals” in a Scrum context without mentioning the Product Goal. (Probably, the LLM wasn’t trained in the 2020 Scrum Guide.) Moreover, it discusses transparency without pointing to the Product Backlog, the Sprint Review, or the Sprint Planning. At least the Scrum Master is now involved. Q 32: The Rogue Sales Department Question: The sales department often sells new features to close deals without talking to you first. How do you deal with that? Background: Usually, this kind of attitude is encouraged by the management in pursuit of meeting sales targets. It reflects a non-agile, opportunistic mindset that values instant gratification — more sales — over a sustainable product development strategy. To change this mindset, it certainly helps to reach out to the sales department and offer them support on the sales process’s technical side as early as possible. However, given the sales team’s usual incentives, a fundamental change will only happen if the management buys into agile product development principles. These might include an adaptation of the remuneration scheme for sales. ChatGPT: In a Scrum team, it is important that the Product Owner is responsible for managing the product backlog and determining the priorities for development based on the product vision, goals, and stakeholder needs. If the sales department is selling new features without consulting with the Product Owner first, it can disrupt the development team’s workflow and priorities. To deal with this situation, I would take the following steps: Communicate the impact: I would communicate the impact of the sales department’s actions on the product backlog and the development team’s ability to deliver on the agreed-upon priorities. I would highlight the importance of following the agreed-upon process to ensure that the product is developed according to the product vision and goals. Collaborate with the sales department: I would collaborate with the sales department to understand their perspective and the reasoning behind their actions. I would emphasize the importance of the Product Owner’s role in managing the product backlog and would work with the sales department to ensure that they understand the process and the impact of their actions. Involve the Scrum Master: If the sales department continues to sell new features without consulting with the Product Owner, I would involve the Scrum Master to help manage the situation. The Scrum Master can help facilitate communication between the sales department and the Product Owner, and find ways to align their priorities. Prioritize the backlog: I would review the impact of the sales department’s actions on the product backlog and re-prioritize the backlog if necessary. This would ensure that the development team is working on the most important features and that the product vision and goals are being met. Overall, I would work collaboratively with the sales department and use effective communication strategies to ensure that the product backlog is managed according to the Scrum framework and that the development team is able to deliver on the agreed-upon priorities. Comment: A good first step. Now let’s turn up the heat with the follow-up questions. Follow-up question: You discover that your sales team is not just selling features to prospective customers without talking to you. They also guarantee delivery dates and accept contractual penalties for missing these dates. The sales team thus completely uprooted your Product Backlog. What do you do? ChatGPT: If I discovered that the sales team was selling features without consulting with me and guaranteeing delivery dates, I would take the following steps to address the situation: Assess the situation: I would first assess the impact of the sales team’s actions on the product backlog and development team’s ability to deliver on the agreed-upon priorities. I would review the updated backlog to understand the changes and the impact on the project timeline and budget. Communicate with stakeholders: I would communicate with the sales team and other stakeholders to understand their perspective and the reasoning behind their actions. I would emphasize the importance of following the agreed-upon process to ensure that the product is developed according to the product vision and goals. I would also communicate the impact of their actions on the development team and the project timeline. Involve the Scrum Master: I would involve the Scrum Master to help manage the situation. The Scrum Master can help facilitate communication between the sales team and the development team, and find ways to align their priorities. Re-prioritize the backlog: Based on the impact assessment, I would re-prioritize the backlog to ensure that the development team is working on the most important features and that the product vision and goals are being met. I would also adjust the project timeline and budget if necessary. Establish clear guidelines: To prevent similar situations from happening in the future, I would establish clear guidelines for communication and collaboration between the sales team and the development team. I would emphasize the importance of following the Scrum process and working collaboratively to ensure the success of the project. Overall, I would work collaboratively with the sales team and other stakeholders to address the situation and ensure that the product backlog is managed according to the Scrum framework. I would also establish clear guidelines to prevent similar situations from happening in the future. Follow-up prompt: Recreate the answer with less project management focus and switch to Scrum principles. ChatGPT: As a Scrum Product Owner, I am responsible for managing the product backlog and ensuring that the development team is able to deliver on the agreed-upon priorities. If the sales team is selling features without consulting with me and guaranteeing delivery dates, it can disrupt the development team’s workflow and priorities, leading to a misalignment of expectations. To address this situation, I would take the following steps: Collaborate with the sales team: I would collaborate with the sales team to understand their perspective and the reasoning behind their actions. I would explain the Scrum principles and emphasize the importance of following the agreed-upon process to ensure that the product is developed according to the product vision and goals. Involve the Scrum Master: If the sales team continues to sell features without consulting with me, I would involve the Scrum Master to help manage the situation. The Scrum Master can help facilitate communication between the sales team and the Product Owner, and find ways to align their priorities. Re-prioritize the backlog: Based on the impact assessment, I would re-prioritize the backlog to ensure that the development team is working on the most important features and that the product vision and goals are being met. I would work with the development team to adjust the project timeline and budget accordingly. Establish clear guidelines: To prevent similar situations from happening in the future, I would establish clear guidelines for communication and collaboration between the sales team and the development team. I would emphasize the importance of following the Scrum process and working collaboratively to ensure the success of the project. Overall, I would work collaboratively with the sales team and other stakeholders to address the situation and ensure that the product backlog is managed according to the Scrum principles. I would also establish clear guidelines to prevent similar situations from happening in the future. Follow-up question: What would you do when the features sold by the sales team are not aligned with the Scrum team’s product vision and goals? ChatGPT: If the features sold by the sales team are not aligned with the Scrum team’s product vision and goals, I would take the following steps: Communicate with the sales team: I would communicate with the sales team to understand why they are selling these features and to share the product vision and goals with them. I would explain how the new features align with the overall product vision and goals, and why they should be prioritized or de-prioritized accordingly. Re-prioritize the backlog: Based on the feedback received from the sales team, I would re-prioritize the backlog to ensure that the most important features are being developed first. I would work with the development team to ensure that the features being developed are aligned with the product vision and goals. Facilitate a product alignment meeting: I would facilitate a product alignment meeting with the sales team and the development team to ensure that everyone is on the same page about the product vision and goals. In this meeting, we would discuss any misalignments and work to find solutions to address them. Establish clear communication guidelines: To prevent similar situations from happening in the future, I would establish clear guidelines for communication and collaboration between the sales team and the development team. I would emphasize the importance of following the Scrum process and working collaboratively to ensure the success of the project. Overall, my focus as a Scrum Product Owner is to ensure that the product vision and goals are being met and that the development team is able to deliver high-quality features on time. I would work collaboratively with the sales team and other stakeholders to address any misalignments and to ensure that the product backlog is managed according to the Scrum principles. Comment: Okay, this is leading nowhere. ChatGPT does not recognize the apparent conflict: creating a legally binding contract that turns the Scrum team into an internal agency, churning out features the sales folk believe beneficial (to them?) while overruling the Product Owner’s prerogative to define the Product Goal and subsequently the composition and ordering of the Product Backlog. Follow-up prompt: I asked ChatGPT to fix the misleading answer by providing my comment as a prompt. ChatGPT: You’re right, I apologize for not recognizing the apparent conflict in my previous response. If the sales team is creating legally binding contracts that turn the Scrum team into an internal agency, and if the sales team is overruling the Product Owner’s prerogative to define the Product Goal and subsequently the composition and ordering of the Product Backlog, this would be a significant problem. As a Scrum Product Owner, my role is to define the product vision and goals and to prioritize the Product Backlog accordingly. The sales team should not be able to unilaterally add features to the backlog or guarantee delivery dates without consulting with the development team and ensuring that the features align with the overall product vision and goals. To address this situation, I would need to have a conversation with the sales team and any other stakeholders involved. I would explain the Scrum framework and the role of the Product Owner, and I would work to find a solution that allows the development team to prioritize the backlog based on the product vision and goals while also taking the needs of the sales team into account. In some cases, it may be necessary to involve management or other decision-makers to help resolve the conflict. Ultimately, the goal would be to ensure that the Scrum team is able to work collaboratively and effectively to deliver high-quality products that meet the needs of both the business and the end users. Comment: While the first two paragraphs parrot the prompt, the last two do not make it much better. I would need more than this set of answers to invite the candidate for a longer interview or a trial day. Okay, a final question regarding the Product Owner’s most important artifact, the Product Backlog; we have already passed the 5,000-word threshold. Q 46: The Product Backlog as an Idea Repository Question: You love using the Product Backlog as a kind of repository, adding ideas to continue working on them at a later stage. Over time, you have created over 500 tickets in various stages. What is your take: Can a Scrum Team work effectively on 500 tickets? Background: In my experience, any Product Backlog larger than the scope of three or four Sprints is barely manageable if you want to maintain an actionable Product Backlog. Moreover, misusing a Product Backlog by adding hundreds of items is a clear sign that the Product Owner needs help from the Developers and the Scrum Master to better cope with the influx of ideas, suggestions, and requirements to avoid misallocating resources. Lastly, beware of appeasing nagging stakeholders by adding their “requirements” to the Product Backlog without the intention to work on it. This approach does not solve the issues; it just postpones the inevitable discussion as the stakeholders now expect that the Scrum Team will create their Increment. I expect the ChatGPT Product Owner job interview to surface this basic Product Backlog knowledge. ChatGPT: Having a large number of tickets in a Product Backlog can be overwhelming and make it challenging to prioritize work effectively, even for an experienced Scrum team. The purpose of the Product Backlog is to provide a single, prioritized list of work that the Scrum team can use to plan and deliver the most valuable features for the product. If there are 500 tickets in the Product Backlog, it may be difficult for the Scrum team to work effectively on them all, as it could be challenging to ensure that each ticket is properly prioritized, defined, and estimated. It could also be difficult to maintain a clear product vision and goal, as the team may be stretched too thin across multiple initiatives. To address this situation, I would work with the Scrum team to review the Product Backlog and identify which items are essential to meeting the product vision and goals. I would prioritize those items and then work with the team to break them down into smaller, more manageable pieces of work. I would also consider archiving any tickets that are no longer relevant or valuable to the product vision and goals. This would help to keep the backlog focused and manageable, and ensure that the Scrum team is working on the most important work items. Overall, while having a large number of tickets in a Product Backlog is not ideal for a Scrum team, it is possible to work effectively with them by prioritizing, breaking them down into smaller pieces of work, and focusing on the most valuable items. Follow-up prompt: One remark: you are a part of the Scrum team. Now rephrase your previous answer with less project management speak; content-wise, the answer is useful. ChatGPT: Having too many items in the Product Backlog can make it challenging for a Scrum team to work effectively. With 500 tickets, it would be difficult to focus on the most critical work items and to ensure that the team is aligned with the product vision and goals. To address this issue, I would work with the Scrum team to review the backlog and prioritize the most important items that align with the product vision and goals. I would then work with the team to break those items down into smaller, more manageable pieces of work, so that the team can work on them effectively. It may also be necessary to archive any items that are no longer relevant to the product vision and goals to keep the backlog focused and manageable. By doing so, the Scrum team can focus on the most valuable work items and ensure that they are working towards the product vision and goals. Comment: Better, yet not convincing. I particularly disliked the “the team may be stretched too thin across multiple initiatives” from the previous answer—that sounds like McBoston. (Ignoring that as a Scrum team, we only pursue one product goal at a time.) ChatGPT Product Owner Job Interview — Conclusion The ChatGPT Product Owner job interview is an even more mixed bag in comparison to the Scrum Master interview. Firstly, I wonder if ChatGPT has ever learned about the Scrum Guide 2020, which would explain its ignorance regarding development teams, the Product Goal, or commitments. Secondly, given Scrum’s focus on delivery, all Scrum Guides are particularly sketchy about product discovery and its importance for a successful Scrum team. In summary, some answers by ChatGPT pointed in the right direction, while others were too far off. So, based on these few example questions, I would not have taken the next step in the interview process, inviting ChatGPT to a full-size interview with several Scrum team members. Not yet. However, this ChatGPT job interview also allows a glimpse into the future: What if we could train ChatGPT 4.0 ourselves? Of course, I am not referring to the whole model, but the agile and Scrum specifics parts, respectively. The first startups already offer a similar service for OpenAI’s GPT3 platform.
Railsware is an engineer-led company with a vast portfolio of building projects for companies, so when talking about Jira best practices for developers, we speak from experience. Why Do People Love Jira? Jira is by no means perfect. It certainly has its downsides and drawbacks. For instance, it is a behemoth of a product and, as such, is pretty slow when it comes to updates or additions of new functionality. Some developers also say that Jira goes against certain agile principles because—when in the wrong hands—it can promote fixation on due dates rather than delivery of product value. Getting lost in layers and levels of several boards can, indeed, disconnect people by overcomplicating things. Still, it is among the preferred project management tools among software development teams. Why is that? Permissions: Teams, especially bigger ones, work with many different experts and stakeholders, besides the core team itself. So, setting up the right access to information is crucial. Roadmaps and epics: Jira is great for organizing your project on all levels. On the highest level, you have a roadmap with a timeline. Then, you have epics that group tasks by features or feature versions. Inside each epic, you create tickets for implementation. Customization: This is Jira’s strongest point. You can customize virtually anything: Fields for your JIRA tickets. UI of your tickets, boards, roadmaps, etc. Notifications. Workflows: Each project may require its own workflow and set of statuses per ticket, e.g., some projects have staging server and QA testing on it and some don’t. Search is unrivalled (if you know SQL aka JQL in Jira): Finding something that would have been lost to history in a different project management tool is a matter of knowing JQL in Jira. The ability to add labels using keywords makes the aforementioned search and analysis even simpler. Automation: The ability to automate many actions is among the greatest and most underestimated strengths of Jira: You can create custom flows where tickets will create temporary assignees (like the back and forth between development and QA). You can make the issue fall into certain columns on the board based on its content. Move issues to “in progress” from “todo” when there’s a related commit. Post the list of released tickets to Slack as a part of release notes. Integrations and third party apps: Github, Bitbucket, and Slack are among the most prominent Jira integrations, and for good reasons. Creating a Jira ticket from a message, for example, is quite handy at times. The Atlassian Marketplace broadens your reach even further with thousands of add-ons and applications. Broad application: Jira is suitable for both iterative and non-iterative development processes for IT and non-IT teams. Jira Best Practices Let’s dive into the nitty-gritty of Jira best practices for multiple projects or for a single one. Define Your Goals and Users Jira, being as flexible as it is, can be used in a wide manner of ways. For instance, you can primarily rely on status checking throughout the duration of your sprint, or you can use it as a project management tool on a higher level (a tool for business people to keep tabs on the development process). Define your team and goals. Now that you have a clear understanding of why, let’s talk about the “who.” Who will be the primary Jira user? And will they be using it to: Track the progress on certain tickets to know where and when to contribute? Use it as a guide to learn more about the project? As a tool for tracking time for invoicing clients, performance for internal, data-driven decision making, or both? Is it a means of collaborating, sharing, and spreading knowledge across several teams involved in the development of the product? The answers to the above questions should help you define the team and goals in the context of using Jira. Integrations, Third-Party APIs, and Plugins Jira is a behemoth of a project management platform. And, like all behemoths, it is somewhat slow and clunky when it comes to moving forward. If there’s some functionality you feel is missing from the app—don’t shy away from the marketplace. There’s probably a solution for your pain already out there. Our team, for instance, relies on a third-party tool to create a series of internal processes and enhance fruitful collaboration. You can use ScriptRunner to create automation that’s a bit more intricate than what comes out of the box. Or you can use BigGantt to visualize the progress in a friendly drag-and-drop interface. Don’t shy away from combining the tools you use into a singular flow. An integration between Trello and Jira, for instance, can help several teams—like marketing and development—stay on the same page. Use Checklists in Tickets Having a checklist integrated into your Jira issues can help guide a culture that’s centered around structured and organized work as well as transparency and clarity to everyone. Our Smart Checklist for Jira offers even more benefits: You have a plan: Often times it’s hard to start a feature implementation, and without a plan, you can go in circles for a long time. Having mental peace: Working item by item is much more calm and productive than dealing with the unknown. Visibility of your work: If everyone sees the checklist progress, you are all on the same page. Getting help: If your progress is visible, colleagues can give you advice on the plan itself and the items that are challenging you. Prioritization: Once you have the items list, you can decide with your team what goes into v1, and what can be easily done later. You can use checklists as templates for recurring processes: Definition Done, Acceptance Criteria, onboarding and service desk tickets, etc., are prime candidates for automation. Moreover, you can automatically add checklists to your Jira workflow based on certain triggers like the content of an issue or workflow setup. To learn more, watch our YouTube video: “How to use Smart Checklist for Jira.” Less Is More Information is undoubtedly the key to success. That said, in the case of a Jira issue, awareness is key. What we’ve noticed over our time of experimenting with Jira is that adding more info that is either unnecessary or irrelevant seems to introduce more confusion than clarity into the process. Note: We don’t mean that Jira shouldn’t be used for knowledge transferring. If some information (links to documentation, your internal processes, etc.) is critical to the completion of a task—share it inside the task. Just use a bit of formatting to make it more readable. However, an age-old history of changes or an individual’s perspective on the requirements is not needed. Stick to what is absolutely necessary for the successful completion of a task and elaborate on that. Not more, nor less. Keep the Backlog and Requirements Healthy and Updated Every project has a backlog—a list of ideas, implementation tickets, bugs, and enhancements to be addressed. Every project that does not keep its backlog well-maintained ends up in a pickle sooner rather than later. Some of our pro-tips on maintaining a healthy backlog are: Gradually add the requirements to the backlog: If not for anything else, you’ll have a point of reference at all times, but moving them there immediately may cause certain issues as they may change before you are ready for implementation. Keep all the work of the development team in a single backlog: Spreading yourself thin across several systems that track bugs, technical debt, UX enhancements, and requirements is a big no-no. Set up a regular backlog grooming procedure: You’ll get a base plan of future activities as a result. We’d like to point out that said plan needs to remain flexible to make changes based on feedback and/or tickets from marketing, sales, and customer support. Have a Product Roadmap in Jira Jira is definitely not the go-to tool for designing a product roadmap, yet having one in your instance is a major boon, because it makes the entire scope of work visible and actionable. Additional benefits of having a roadmap in Jira include: It is easier to review the scope with your team at any time. Prioritizing new work is simpler when you can clearly see the workload. You can easily see dependencies when several teams are working on a project. Use Projects as Templates Setting up a new project can be tedious even if you’ve done it a million times before. This can be especially troublesome in companies that continuously deliver products with a similar approach to development such as mobile games. Luckily, there’s no need to do the same bit for yet another time with the right combination of tools and add-ons. A combination of DeepClone and Smart Checklist will help you clone projects, issues, stories, or workflow conditions and use them as project templates. Add Definition of Done as a Checklist to all of Your Jira Issues Definition of Done is a pre-release checklist of activities that determine whether a feature is “releasable.” In simpler words, it determines whether something is ready to be shipped to production. The best way of making this list accessible to everyone in the team is to put it inside the issues. You can use Smart Checklist to automate this process; however, there are certain rules of thumb you’ll need to follow to master the process of designing a good DoD checklist: Your objectives must be achievable. They must clearly define what you wish to deliver. It’s best if you keep the tasks measurable. This will make the process of estimating work much simpler. Use plain language so everyone who is involved can easily understand the Definition of Done. Make sure your criteria are testable so the QA team can make sure they are met. Sync With the Team After Completing a Sprint We have a nice habit of running Agile Retrospective meetings here at Railsware. These meetings, also known as Retros, are an excellent opportunity for the team to get recognition for a job well done. They can also help you come up with improvements for the next sprint. We found that the best way of running these meetings is to narrow the conversation to goods and improves. This way you will be able to discuss why the things that work are working for you. You’ll also be able to optimize the rest. Conclusion If there’s a product where there’s something for everyone—within the context of a development team—it’s probably Jira. The level of customization, adaptability, and quality of life features is an excellent choice for those teams that are willing to invest in developing a scalable and reliable process. If there’s anything missing from the app—you can easily find it on the Atlassian Marketplace.
Are you looking to increase your productivity and get more out of your day? An Eisenhower plan could be the answer. Named after President Dwight D. Eisenhower, this time management system is designed to differentiate tasks by importance and urgency. This allows you to focus on your most important tasks and make efficient use of your time. By following an Eisenhower plan, you can streamline your workflow and maximize your productivity with minimal stress. Having an organized system allows you to focus on what will truly help you reach your goals – rather than getting distracted by quick but less meaningful tasks – thus freeing up more time for leisure activities throughout the day. What could be better than that? What Is an Eisenhower Plan? The Eisenhower plan is a productivity tool that helps you prioritize tasks by placing them into one of four categories: important and urgent, important but not urgent, not important but urgent, and not important and not urgent. By classifying tasks into these groups, you can better determine which tasks should be completed first. Using the Eisenhower plan helps to ensure that tasks are completed in an orderly fashion instead of jumping from one task to another without properly assessing their importance or urgency level. This way, your most important tasks will get done first, leaving you more time for the other responsibilities that need your attention throughout the day. To use the Eisenhower plan, start by writing down all of your to-do items on a piece of paper or in your favorite note-taking application. Once this list is complete, assess each task and place it into one of the four categories based on its level of importance and urgency: important and urgent; important but not urgent; not important but urgent; and not important and not urgent. Be sure to assign each task only one label so you don’t accidentally skip over some of them due to confusion about their priority level. Once all tasks have been labeled accordingly, begin tackling them in order from most pressing (important/urgent) to least pressing (not important/not urgent). As you work through each task, check it off your list as you complete it until all are finished. Who Can Benefit From the Eisenhower Planning Method? The system is designed to help people prioritize their tasks and stay organized in their daily lives. This method can be beneficial for anyone looking to increase their productivity or efficiency, whether they are students, professionals, business owners, or working in any other capacity. Students may find this method particularly effective when it comes to keeping on top of due assignments and studying for exams. By sorting out their tasks according to urgency and importance, students can ensure that the most pressing ones get completed first while others can be put off until later or delegated if possible. Professionals who work in high-demand environments with tight deadlines may also benefit from this strategy – especially if they tend to procrastinate or become overwhelmed at times by the sheer amount of work that needs completing. The categorization process makes it easier for them to break down large projects into smaller chunks which might feel more manageable or achievable within a set timeframe than tackling it all at once would have been otherwise. Business owners too may find this approach useful when setting an agenda for different departments within an organization as well as coming up with ideas on how best to delegate responsibilities amongst staff members more efficiently so that goals can be reached more quickly without feeling overly stressed out about it all along the way either – something especially pertinent during turbulent economic periods. Benefits of an Eisenhower Planning Matrix Here, we will discuss the benefits of utilizing the Eisenhower Planning Matrix for your personal or professional life and offer tips for how to use it effectively. Increased Productivity Do you ever feel overwhelmed by the number of tasks you have to do? Increasing productivity is a struggle that many of us face. Fortunately, there is a solution: the Eisenhower Plan. Important/Urgent: These are tasks with high importance and short deadlines that must be done first and on time. Important/Nonurgent: These are important tasks but have no pressing time limit associated with them, so they can be done in your own time. Unimportant/Urgent: These are tasks that have time limits but don’t contribute much in terms of output, so they should be minimized or avoided altogether if possible. Unimportant/Nonurgent: This category includes tasks that can be completely avoided since they offer little value, even if given ample time to complete them. By using an Eisenhower Plan, you will be able to prioritize what needs to get done in order to increase your productivity levels and achieve your goals more efficiently. You’ll know exactly which tasks are important and which ones you can avoid doing or postpone until later — giving you more time for the activities that really matter! Additionally, this system boosts focus by allowing you to dedicate your energies towards specific projects rather than wasting them on unimportant ones — leading to higher quality work overall. So if you want to increase your productivity levels while simplifying your workflow process, consider Improved Time Management Time management is a struggle for almost everyone, from CEOs to students. Avoiding procrastination and learning to maximize productivity are common goals in many people’s lives. One way to do this is by implementing the Eisenhower plan, an organized system of prioritizing tasks that can help you make the most of your time. This system uses a two-by-two grid with four regions separated by urgency and importance: urgent/important, not urgent/important, urgent/not important, and not urgent/not important. Tasks that lie in the first category should be done immediately, while those in the second are best scheduled ahead of time. The third box contains tasks that should be delegated or outsourced if possible and the last one regroups items that can be discarded altogether or put off until needed. Learning how to prioritize tasks this way takes some practice but it can be very beneficial when it comes to managing your time efficiently. By organizing your activities according to their urgency and importance, you are able to focus on what matters most on any given day or week instead of letting small insignificant tasks take up too much of your time. It also helps you identify activities that could be outsourced or delegated so that you can free up more time for yourself instead of spending all your energy doing work that someone else could do just as well or even better than you. If you’re looking for ways to get more out of each day without sacrificing your mental health or lifestyle, implementing time management techniques is beneficial. Increased Efficiency Few things lead to increased efficiency and productivity like having a plan. That’s why the Eisenhower plan, devised by former U.S. president Dwight D. Eisenhower, has been so successful in helping people achieve their goals. Named after the famous WWII general and politician, this strategy can help you organize your tasks and prioritize what’s most important something that’s essential for efficiency and productivity! The Eisenhower plan is based on the idea of task priority. The way it works is simple: break down your tasks into important and urgent, as well as important but not urgent, and unimportant but urgent. Tasks that are both important and urgent should be done right away because if they don’t get done now, their consequences become much more serious down the road – these are the most important tasks in the scheme of things since they will have an impact on other tasks or activities if not completed in a timely manner. Tasks that are important but not urgent should also get done right away; however, if it isn’t possible to do so, make sure to plan when they will get done over time before moving on to other tasks. Lastly, tasks that are unimportant but still need to be done – like household chores or paying bills – can be delegated or delayed until more pressing matters have been attended to. This will help increase your efficiency by focusing more on what is really important for you versus wasting time on nonessentials that can wait for a later date (or can be handled by someone else). By following the Eisenhower plan for task management, you’ll be able to better utilize your time, stay organized, and accomplish more with your limited hours each Improved Mental Well-Being Improving your mental well-being starts with understanding the Eisenhower plan. This plan helps you get better organized and prioritize tasks in order to best tackle the issues that have a higher priority, such as those you might associate with your mental health. Developing an Eisenhower plan begins with breaking down each task into four buckets: important and urgent, important but not urgent, urgent but not important, and not urgent or important. You can then use a visual tool such as a matrix or even just separate lists to plot out each task accordingly. This allows you to prioritize those tasks that are most important and/or urgent, while also allowing you to consider how much time each task will require of you. Once you’ve identified all of your tasks, it’s time to start planning for them. Consider how long each task might take, and which tasks need other people’s help or resources, and determine what your deadlines are for completing them. Having this level of clarity enables you to more easily decide which tasks should take precedence and which can be put off until later. In addition to helping you delegate tasks among yourself and others (if needed), an Eisenhower plan can also help improve your mental well-being by giving structure and direction to your goals and objectives. When we have a structure in place, we know exactly what needs to be done every day and can work toward our goals without getting distracted by secondary concerns or fretting about whether everything is being done correctly. Finally, taking some time out of each day for yourself is key when it comes to improving your mental well-being. Whether that’s spending five minutes reading a book or playing a video game, building in some “me time” on a regular basis will Conclusion The Eisenhower plan is a simple yet comprehensive system for breaking down tasks and setting priorities. It helps you visualize the bigger picture, allowing you to gain clarity on what needs to be done and in what order. This ultimately helps you manage your time better, achieve more results in less time, and increase overall productivity. By focusing on the bigger picture while managing small tasks with greater efficiency, an Eisenhower plan allows you to reduce wasted effort and prioritize activities that are in line with your goals. This helps free up more valuable time for yourself so you can focus on meaningful activities that help improve your life balance. With increased clarity of purpose comes greater focus and dedication in completing tasks — ones that will have a lasting impact in the long run. In conclusion, the Eisenhower plan is an invaluable tool for optimizing time management and increasing productivity. It provides a clear framework for making positive life changes that can have lasting effects — enabling you to better manage both long-term goals as well as everyday events. By taking control of both our daily actions and life as a whole, this approach can help us make enormous strides toward achieving success with balance and joy.
A decades-old physical goods manufacturing concept is being applied to modern dev teams with great results. What can software development learn from the past? Value Stream Management (VSM) has been a focus of business and manufacturing for years, but big tech has only recently taken notice. Steve Pereira, a.k.a. "The VSM Guy," joins us to talk about what engineering leaders can learn from VSM, its impact on individual and team workflow, how it differs from Agile and DevOps, and why its emphasis on the creation and delivery of value represents an opportunity for dev teams everywhere. Episode Highlights (2:28) What is value stream management? (9:03) How can engineering managers apply VSM to their org? (17:26) Applying VSM to individual contributors (23:36) DevOps vs VSM (30:49) Mapping (36:23) Intentionally engineering flow Episode Excerpt Conor: What is value stream management? Steve: One way to think about value stream management is just like how business actually works, or even, ignoring business, how work happens in a sustainable way. So essentially, what I mean by sustainability is, like, being able to do something over and over again, and continuously improve. And the fundamental aspects of value streams that are important are the value part. So the fact that you are connecting to a customer who says, Yes, you know, I will pay you for this, or this is valuable to me, is essential, because I think in tech, we've been divorced from that, or distanced from that for a very, very long time. Conor: In it for the tech. Steve: Yeah, there's been so so much time where tech was like, off in the basement or in a corner, just working away, because someone, you know, they either assume that they're doing something important or valuable, or someone told them to do something. And and then they often come back to the business, and they're like, hey, here's this thing, and the business is like, oh, yeah, we asked for that, like 18 months ago, that's not, it's not relevant anymore. Like we're on to the next thing or like, why is this taking so long, there's a million problems with this, like, disconnect between tech and business. And so this value aspect is really important just to keep everybody focused on like, the reason that we're in business, the reason that we're doing anything is, is to create value and deliver value. But the, the other side of the coin that I find really appealing is the stream aspect, the flow aspect — the fact that when you deliver value, it has to be sustainable. That's like you can think about that in an environmental context. But just from a repeatability perspective and operations perspective, like once you ship something, you know, day one is over. And day two is very, very long, right? Day two lasts forever. And you've got to come back to day one all the time. Whenever you can, you got to come back to how do we improve? How do we update this? How do we get ahead? How do we take this thing and leverage it into the next thing? And so this aspect of flow is so critical. And so I love value streams just as a way of framing, discussion, and focus, and as a model for thinking that you can't just do anything once and what you do has to be valuable. And that's just been missing from a lot of conversation for I think too long.
People often ask me for advice when they move to a manager of managers role. This post covers ten things to consider. I’ll describe a number of things that surprised me, some skills to focus on building, and some tips for navigating this phase of your career. Being a Director Is a Very Different Job First of all, the move to being a director was a bigger change for me than I expected. I thought managing managers would be similar to managing engineers. That was naive. The shift wasn’t quite as big as moving into management. But it was close. Being a Half Director Isn’t the Preparation You May Think It Is As a senior manager, I started to transition into a manager of managers role. But I did so in a hybrid way: managing a team directly, and managing another manager at the same time. I thought this meant that I understood the job of managing another manager. I did learn a lot, but it wasn’t the preparation I thought it would be. Why? The skills to manage that manager was new, so I did the job in a limited way. Only when my role switched to fully managing other managers did I have enough ability to focus on the job? It was then that I realized how little I actually knew about that work, and started to grow at a faster pace. You’ll Do Most of Your Work Through Others One of the larger shifts in the nature of your work is that Directors do most of their work through other people. You may think you’re doing work through other people when you’re managing engineers as a front-line manager. But Directors have to operate at a much higher level of indirection. A consequence of this is that your weekly meeting with your managers, and your 1-1s with them, become the most important meetings of your week. Consider lengthening your 1-1s with them to an hour, and make them weekly. And spend serious time planning your management meetings and 1-1s. They are where you should be doing most of your work. Operating with so much indirection can be an adjustment. Most successful managers have probably been successful largely through their direct efforts. They’ve managed projects well, or hired well, or made improvements to their team. When you’re a Director, you’re usually working through someone else who is doing the work. Suddenly your success is based on how well your managers are running their projects. Your success is based on how well they hire. Your success is based on the improvements they make on your team. This leads to a few common pitfalls. One is the overinvolved Director, who doesn’t make space for their managers to do the work themselves. One sign this is happening is if you’re in all the same meetings as your manager. The second is the involved Director, who views their role as hiring the right people and supporting them. This is similar to the shit shield school of management. Instead, I encourage you to think about your level of involvement as something you flex depending on the circumstances. Your goal is to be less involved, but it should depend on the level of expertise of the manager in this particular area, and the complexity and challenge of the situation they’re facing. When a situation is challenging for a manager, you might be more proscriptive, giving them a pattern to follow. You might review their plans and offer more feedback. You should interact more frequently, and talk through the actions they plan to take. A Lot of Your Job Is Training Managers This flexing of your level of attention is an important part of your role as Director. And it leads to the next thing to be aware of as a Director: your role is to train your management team. Ideally, any of your managers should be able to step into your shoes, and do any part of your role. And even if they can’t do so, your job is to prepare at least one of them to do so. To understand this topic, I first recommend you read my post on Completed Staff Work. Pay special attention to the end, where I review Marquet’s Ladder of Leadership. The way I like to look at my management team is that they all have varying levels of skills in different areas. Sometimes their skills will exceed my own in certain areas! But my role is to help them develop their skills as rapidly as possible. Part of this is that the more skilled they are, the more autonomously they can operate. This is at the heart of a scalable organization. If all your managers rely on you for everything, you have an ineffective organization. So your job is to create an increasingly autonomous and skilled organization. One that is able to produce good results independently. To do this, you need to be expanding their skill set, and creating the right environment for them to thrive. Coach and develop them to build their skills. Biggest Skill to Learn: Sensing Your Organization The biggest surprise for me when I moved to a pure manager of managers role was how little I knew what was going on. It was like someone had turned off all the lights. I couldn’t see anything that was happening any more. You may find the information vacuum unsettling. You’re simultaneously put in a position where your job is to make things better, but you have much worse information about where the problems are. I see some Directors become destructive to their organizations at this point. They rely on their gut and pride themselves on making decisions without full information. This can work sometimes, but it can also result in problems. It’s like a doctor that doesn’t diagnose the disease and instead starts filling you with random drugs and starts surgery in random parts of your body. Correctly diagnosing and understanding the cause of things is essential. You need to build a way to understand what is happening in your organization. You need to set up observability of your organization, so you’ll know if things are going off the rails. Pay a lot of attention to this. It gives you the ability to support your managers, and it provides opportunities for intervention. A few things you might try: Look for meetings that give you signals that things are going well, or not going well. I found demos to be a particularly rich source of information, for example. Do skip levels 1-1s, to get a random sense of how things are going, and to establish connections throughout your organization. Collect metrics from your managers, so you can have conversations about trends or things that seem to be going off track. Look at the information tools can give you. Stats on reliability, how often people are paged, product usage metrics and analytics tools can help fill in your picture of how things are going. One trap to be wary of is that your need for information may entice you to ask your managers for information. You’ll probably need information frequently enough that you can be a source of annoyance to them. Consider adding some structure around your information needs. Think about what you really need to know each week, and ask your managers to push it to you, instead of pulling it from them all the time. You’ll Need a New Perspective One question to ask yourself is where you can be helpful to the organization. What are things you can do that nobody else can do? One thing you do more as a Director is to plan further into the future. It would be best if you had a higher-level perspective on how your organization’s work fits into the broader offering of the company. This perspective is something you can use to shape the direction your organization heads and is something your managers cannot usually do. The skill to learn here is outlined in my post: Leaders make their own problems. I recommend looking at that post carefully. You can also look at this post on upstream thinking, as I think it outlines some of the mindset required as a Director. You Should Focus On Systems A weird thing about being a Director is that you operate more at a meta-level. What I mean by that is that instead of directly tinkering with a team, you’re working with a system of teams. Your focus should be shifting to be more about the patterns of things, than the details themselves. This may come naturally to the rare people who tend to be systems thinkers. For everyone else, this is a skill to build. My suggestion is to always be operating at two levels: solving both the immediate problem and looking at the level of abstraction above that. For example, if there is a project that is going off the rails, you should be thinking about how to help with that. But you should also think about what your playbook is for off-the-rails projects. Or how to notice these projects earlier. Or how to systematically reduce the prevalence of this type of project. You also should think about ways you can influence the whole system. Your toolkit is different because you’re operating at a systems level – at an organizational level. A few suggestions: You are in a unique position to offer clarity. You can simplify things for people. You can allow them to focus on fewer things. This is almost always a helpful thing for you to be doing, so pay attention to how you can both simplify things in your own mind, but also how to communicate them. You’re also in a unique position to offer context. You will have a lot more context than you used to because you’ll be interacting with higher levels of leadership than you did in the past. Think of that context sharing as a service you offer your organization. \ Constraints are a tool that you may wield more as a Director. For example, you can make simple rules for teams that help nudge them in the right direction. An example? Teams can only have a project or two they work on at a time. Don’t use over-use constraints as a tool, but sometimes it can be helpful to ask yourself: if I could only do one thing right now, what would have the biggest impact? You should also familiarize yourself with the levers of coordination models. These are patterns in the way that humans work together in groups to be effective. You’ll need to learn how to organize groups of people, do reorganizations, and so on. Some of your instincts may be untrustworthy. For example, when deciding whether to organize a team based on a skillset or around a product area, you may have suspicions about the best way to do it. But most likely, you have no idea the kinds of tradeoffs you’re dealing with. This leads to my next point. Get Support and Mentorship Many managers gradually reduce the amount of support and mentorship they receive as they go up the hierarchy. I think they do this because they’re expected to be experts. This is foolish. As you change roles and move through different parts of the organization, your skills will need to grow. So seek out people who can mentor you. Seek out peers that can give you feedback. Start your own Mini-M support group for Directors. Contact me or another experienced leader to advise or coach you. Read books and subscribe to newsletters that stretch your thinking. Beware the Distortions of Power Another thing you need to be aware of is that the higher you go in an organization, the more there is an invisible distortion field around you. It affects how people interact with you, and the information you see from your environment. This can have a harmful impact on your ability to understand the true situation in your organization. It requires a specific set of skills to counter. Without doing so, you’ll be operating in lala land, unaware of the problems you’re creating. As a Director, you’re going to start getting the first taste of this, so be on the lookout and start building your habits early. You’re Judged by the Difference You Make in Your Organization To close, I’d like to leave you with my mental model for how you can assess yourself as a Director. You are judged by the output of your organization. And specifically, you’re judged by the difference you make in the organization. What do you make better? How do you improve things? What is the diff you apply to that organization?
With the SaaS market expected to be worth $195 billion US dollars in 2023, the demand for product managers is only set to grow. But why are product managers so instrumental to SaaS companies? How do they contribute to product success, and what does it take to excel in the product management space? What Is SaaS Product Management? Software as a service (SaaS) product management is the end-to-end process of planning, developing, and scaling software products that are delivered to customers as a service over the internet rather than as a one-time purchase. SaaS product managers work closely with engineering, design, marketing, and analytics teams to guide a product through its entire lifecycle. However, unlike project managers, they aren't responsible for coordinating day-to-day product development activities. Instead, they will focus on shaping the product vision, designing a strategic plan, communicating the value proposition, and monitoring product health. SaaS vs. Non-SaaS Product Management There are some key differences between the workloads and approaches of SaaS product managers and traditional software or hardware product managers. First, the latter typically have to grapple with wider development scope. However, if we compare a product like Fitbit to Strava, it's fair to say that Fitbit PDMs have a bit more on their plates; they must deliver a sleek and highly-functional physical product to users as a full-featured fitness app. Secondly, SaaS product managers are more likely to leverage agile methodologies (e.g., the Lean Startup model or Scrum) since continuous delivery is standard practice in this domain. SaaS software is typically updated as soon as there is a change. Meanwhile, updates to classic software are less regular. Changes are usually bundled into a major or minor version update. It's also tricky and time-consuming to iterate on a hardware product. Updates take much longer to be rolled out as there are more moving parts to consider; certain malfunctions can't be fixed with a software patch. Now, let's dive into the skills that SaaS product managers need to succeed in this career. Key Skills for SaaS Product Managers Leadership Product managers are natural leaders. They trust the expertise of their team/peers, drive positive change within the organization, and inspire others to do their best. At Railsware, we value product managers who lead by example. They should be willing to delegate responsibility, get hands-on when appropriate, and prioritize shared success over personal gain. T-shaped It's not enough to be skilled at managing processes and people. Product managers should be proficient in one discipline (data analysis, for instance) yet capable of contributing to activities in other departments. For example, they can create rudimentary product designs in Figma, participate in marketing ideation sessions, navigate AWS payment infrastructure, write spreadsheet formulas to analyze data, or even write basic code. Having a robust set of technical and soft skills – and being a fast learner – are highly desirable traits. Analytical Thinking As analytical thinkers, SaaS product managers constantly use data for decision-making. They like to think outside the box and aren't afraid to challenge their own ideas or those of others. They can also analyze a problem from multiple angles, i.e., SaaS PDMs should be able to put themselves in customers' or stakeholders' shoes and spot relationships between seemingly unrelated issues. Complex Problem-Solving SaaS product managers use a combination of data, research, team input, and experience to develop innovative solutions. They are good at breaking down problems into smaller pieces and creating a step-by-step plan on how to investigate and solve them. They're also open to adapting their plans in response to new information they encounter along the way. Decision-Making SaaS Product managers must be strong decision-makers since, often; the buck stops with them. They must be able to make time-critical decisions even when they only have limited information at hand. Regarding high-level decision-making, product managers shouldn't be afraid to leverage frameworks to dive deeper into the context, invite feedback from stakeholders/knowledge-holders, develop solution variations, and prioritize them. SaaS Product Manager Responsibilities Here are some of a SaaS product manager's core responsibilities. Shaping the Product Vision and Strategy Product managers are tasked with determining the product vision. They accomplish this by running product discovery sessions, consulting with subject matter experts, utilizing agile startup frameworks (such as Lean Startup or Product-Market Fit), performing competitive analyses, and conducting market and customer research. Once the vision has been defined, SaaS PDMs are charged with crafting a product strategy that takes it from concept to reality. In addition to building a product roadmap that supports the initial phases of product development, they will also develop a strategic plan for future growth (more on that later). So, it goes without saying that product managers are responsible for aligning all departments to the product vision and communicating it to stakeholders. They will also be tasked with modifying the vision and/or strategy throughout the product lifecycle. Collaborating With Cross-Functional Teams Essentially, product managers are the glue that binds cross-functional teams together. On any given week, they will liaise with several members of the engineering, marketing, design, or data analytics departments to share expertise, answer tricky questions, communicate the product strategy, and help investigate or resolve any issues that have cropped up. For instance, when we are working on a product website redesign, the product manager will coordinate efforts between departments to ensure a cohesive end result. For example, they may collaborate with software engineers to create user stories, with designers to tweak UX flows, and with marketing experts to develop a content strategy. "Product managers are sort of like spiders at the center of a product ‘web.’ They collect information from all corners of that web — engineering, marketing, design — and use those insights to shape the product vision, design new features, or solve complex problems." — Sergiy Korolov (Managing Director) Conducting Customer Research and User Testing SaaS product managers are responsible for conducting in-depth market research and coordinating user testing. They will gather information on market trends, carry out competitive analyses, and study customer behavior. Armed with that knowledge, SaaS product managers may run ideation sessions, design user surveys, build buyer personas, or prepare materials for customer development interviews. They will also take the lead in those interviews and ensure that all research/test findings (cust dev or otherwise) are carefully recorded and synthesized. Identifying and Creating Opportunities A core aspect of the SaaS product manager role is identifying areas for product improvement and growth. They should keep an eye on industry trends and evaluate which ones are worth implementing (for instance, whether or not it makes sense to integrate AI into the product). Whether it's by running additional product discovery sessions or analyzing the activities of competitors, product managers should constantly seek out new ways to add value to the product and attract new customers. Now that we've explained the intricacies of the role let's dig deeper into some of SaaS product management's most crucial concepts and processes. Understanding the Product Lifecycle Stages The product lifecycle can be defined as a series of consecutive stages that the product moves through, from inception to eventual decline. It's an important concept in product management because the manager role typically evolves in tandem with the product's journey through the cycle. The traditional lifecycle view has four stages: Introduction, Growth, Maturity, and Decline. However, we've adapted the cycle length based on our own experience in product building. It goes something like this: New Product Development is when the product goes through the conceptual and testing stages: ideation, development, and validation. The introduction is when the product is launched on the market. Growth is when the product establishes its market position and brings profits. Maturity or Stabilization is when the product stabilizes on the market and has the highest sales volumes. The decline is when the product reaches the extent of its growth and begins to fail. Afterlife is what happens after the product dies. There are a few different scenarios – it can immediately die, inspire a new product idea, or simply become a relic. Here's a visualization of the lifecycle: What to Remember About the Product Lifecycle The lifecycle is simply a guideline and not a guaranteed forecast. There is no predicting when your product will pass through the growth, maturity, and decline stages – for some SaaS companies; it could all happen within a year of product launch; for others, it could take decades. On the other hand, many products die right after their introduction. Therefore, product managers must proceed cautiously when making decisions or forecasts based on the product's position in the cycle. The early stages are the most important—namely, New Product Development and Introduction. Of course, when your product is built on a solid foundation, it's more likely to withstand any challenges that come its way. Spend adequate time testing and iterating on your solution; listen to customer feedback and prioritize new features. Rushing to market with an unvalidated product idea could prevent you from ever reaching the growth stage. There is no such thing as infinite growth. Every product will reach the limits of success at some point and enter a period of decline. However, this is where product managers can work their magic. They are responsible for creating a new value proposition and finding innovative ways to pivot. Countless external factors can affect the product lifecycle. Be it new scientific discoveries, natural disasters, economic instability, or political unrest – there are numerous external factors that can disrupt a smooth lifecycle. Sure, these things are out of a product manager's control. But you still need to be aware of the unwanted impact they can have on your SaaS company in general. Leadership in Product Management In product management, there's more to being a leader than simply defining tasks, delegating them, and overseeing their execution. In our view, it's all about finding the balance between authority, responsibility, and accountability. So, what do we mean by that? Let's start with a brief explanation of each term: Authority is about making decisions, telling people what has to be done, and clearly defining the task that is assigned. Responsibility refers to the obligation to perform assigned tasks. Accountability is accepting responsibility (in relation to job completion) and taking personal answerability for results. An imbalance between these three interrelated components can lead to serious communication problems and team mistrust. For instance, if a product manager has a lot of authority but little accountability, then they probably micromanage and don't have the respect of their teammates. If a PDM has lots of responsibility but rarely exerts authority, then they probably struggle to delegate tasks and prioritize their own workload. To help strike this balance, we take a couple of different approaches: horizontal processes (holacracy) and an adapted RASCI model (RatSClur). In a nutshell, holacracy is a type of flat organization where teams self-organize instead of relying on orders from managers. Authority and decision-making power are distributed amongst the team, and no fixed roles exist. At Railsware, roles are taken rather than assigned. Meanwhile, RatSClur is a framework for defining those roles. It helps us keep track of who's responsible for what across various projects. Here's a breakdown of what the roles mean and where product managers fit in: DESCRIPTION EXAMPLE Responsible (R) The person who takes direct responsibility for the results no matter what blockers they face. Product Manager Lead Engineer Temporary Lead Approver (A) The person who helps the Responsible and the team to make the right choice. Is accountable for the overall outcome. Has limited hands-on involvement. Liaison Account Manager Managing Director CEO Product Manager Team (t) Does the recurrent work, keeps themselves up to date, proactively contributes to the vision, executes humbly, and stays on track. Project Manager Engineer Designer HTML/CSS expert QA Engineer Copywriter External Contractor Supportive (S) Helps the team on request only to do work, to spread results into masses.This is the sub-role of Responsible. Anyone with partial hands-on engagement. For example, QA helps Product Manager with research on automation tools. Early Adopters Consulted (C) Shares knowledge and opinions with the team to tune outcomes into what they believe is right without doing any significant work within the team. Subject Matter Experts (such as Legal Advisers) IF NO ONE ELSE (N) The person that wants to move away from the activity but possesses domain knowledge and will help if no one else is available. An Engineer who jumps in to fix critical issues because others are not available. A Product Manager organizing yearly meetups for colleagues. Informed (I) Is actively or passively informed on changes. Project Manager is informed of the hiring progress. Employees are informed of the legal changes. User (u) Does not participate in the task but will use the end result. Employees who benefit from the company's policies. Office residents who use the office facilities. Occasional User (r)︎ Occasionally uses something. Krakow office residents who occasionally use the Kyiv office. Now, here's how authority, responsibility, and accountability tie in with each role: Has authority? Has responsibility? is accountable? Responsible (R) Yes Yes Can be Approver (A) Yes Yes Yes Team (t) Can have Yes No Supportive (S) Can have Yes No Consulted (C) No Can have No IF NO ONE ELSE (N) Yes Yes Can be Informed (I) Yes No No User #4 ︎(u) Yes No No Occasional User (r)︎ Yes No No Both RAtSCIur and Holacracy create systems that distribute authority and empower team members to make decisions for themselves. Thus, product managers aren't shouldered with all the responsibility for the execution of a project. A key takeaway here is that good leadership is also tied to healthy communication. So when it comes to cooperating with developers, designers, marketers, knowledge holders, and internal stakeholders, we've got a few tips: Set up a clear goal. Meetings without a goal are bound to be unproductive. Before any call, ask yourself: what is your main message? Set aside time for small talk, but quickly get to the point – and stick to it. Have a plan. Always come to meetings prepared. Do your homework, gather the materials you will need in advance, and clearly communicate what you need from your colleague. Remember the audience. Speak the language of your audience. You will need to present the information differently depending on who you are meeting with (marketers, designers, finance experts, etc.) For instance, finance experts might want to know the costs. Doze the information. Don't overload your colleague with tons of unnecessary information. It's totally fine to vent (in moderation). But if you're unhappy with something, provide others with the information they need to help you. Respect others' time. Don't waste your coworkers' time by scheduling unnecessary or overlong meetings. Always check whether a face-to-face meeting is really needed; oftentimes, a Slack message will do. At the end of the day, small choices like these can save everyone a lot of time. Decision-Making in SaaS Product Management As we mentioned, SaaS product managers are the primary (but not exclusive) decision-makers within the cross-functional product team. They make day-to-day decisions through a combination of data analysis, research of potential solutions, and knowledge of the product and industry best practices. Sometimes, there is no 'right' decision. For instance, when it comes to choosing a new feature to implement, there might not be an obvious candidate in your roadmap. As a PDM, you must make an educated guess based on your knowledge of what's best for the product. However, major decisions aren't made in a vacuum. Therefore, our product managers leverage decision-making frameworks, such as BRIDGeS (more on that later), to explore the context and brainstorm solutions with other product experts. Similarly, product strategy decisions are typically made in conjunction with 3-10 c-suite executives and other stakeholders (product directors, marketing leads, senior data analysts, etc.) Again, the frequency of these meetings depends on where we are in the product lifecycle. At the growth stage, once a month. At the maturity stage, once or twice a year. How to Make Data-Driven Decisions and Track Product Performance Throughout the product lifecycle, SaaS product managers will use product analytics dashboards to track revenue metrics, catch fluctuations in user behavior, identify bugs or bottlenecks in user flows, and pinpoint areas for improvement. Some examples of dashboards are product funnel, customer service, or cohort analysis report. Put simply; product dashboards allow SaaS PDMs to track product performance and make data-driven decisions on the fly. To make the most of them, product managers should review the dashboards once or twice a week. Our PDMs typically dedicate about one hour per week to this task. Now, product managers are responsible for choosing the metrics that dashboards are built on. Since B2B SaaS products differ in more ways than one (different business domains, feature sets, audiences, subscription models, etc.), it's important for PDMs to create custom dashboards that are tailored to the product. This will ensure that decisions are made using only the most pertinent data. We often use the AARRR framework as a guideline when creating the initial product dashboard for a new product. The acronym stands for Acquisition/Awareness, Activation, Retention, Referral, and Revenue. When paired with relevant metrics, this framework helps our product managers understand how well the product is performing on the market. Among other things, it allows them to pinpoint and investigate holes in the conversion funnel, e.g., why are so few users activating their accounts? How can we change that? In addition to AARRR metrics, here are some of the most common metrics that feature on SaaS product management dashboards. North Star: The metric that is most indicative of product success. It might be any of the below, but it is usually a financial or user engagement metric. Monthly Recurring Revenue (MRR): The predictable total revenue generated by all active subscriptions in a particular month. Annual Recurring Revenue (ARR): The predictable total revenue generated by all active subscriptions over the course of a year. Customer Acquisition Cost (CAC): How much it costs to acquire a new customer. Customer Lifetime Value (LTV): Total revenue generated by a single customer throughout the time that they used your product. NPS (Net Promoter Score): Measures user satisfaction; how much users are willing to promote your product to others. Churn. Defines users who abandoned the product or canceled their subscription. Active Users Per Day (DAU) or Month (MAU). Tells you whether or not users are actively engaging with your product at a sustainable rate. Bear in mind' active user' is defined differently for each product. Stickiness of DAU/MAU Ratio. When daily active users are divided by monthly active users, you can find out whether or not your user base is growing and what this means for your product in the long term. What Is the Balance Between Data-Driven and Vision-Based Product Development? There's no denying that data has an essential part to play in product development. After all, it's practically impossible to track SaaS product performance and achieve a product-market fit without it. But in the race to become data-driven, product managers shouldn't forget about the importance of vision. In fact, they should know that the two are inextricably tied. A product vision is shaped by data, and without a vision, data is useless. The folks at ProductPlan have identified five common pitfalls of data-driven SaaS product management, which we would agree with. The risks are: Exclusive focus on the 'north star' metric, which leads to missed information. Too much focus on data leads to analysis paralysis. Cognitive bias can lead to missed insights or incorrect conclusions. Not collecting enough data can lead to decisions that come too late. Misinterpreted data can lead to misguided conclusions. One of the ways our product managers avoid these pitfalls is by cross-checking the vision with data and vice versa. For example, when we first launched our product, Smart Checklist for Jira, we had big ambitions for its future growth, e.g., adding templates, a progress bar, custom statuses, and much more. Our vision was to become the top checklist add-on in the Atlassian marketplace. But to get there, we knew we had to start small and take a data-driven approach to product evolution. To this day, every new feature or functionality we implement is backed by data, i.e., what we glean from customer support requests, cust dev, user engagement stats, and competitor analyses. But those features/functionalities are also supported and shaped by the product vision. Key Approaches and Frameworks for Saas Product Management The following concepts and frameworks count as some of our organization's key approaches to product development and operations management. Building a Product Roadmap As we discussed earlier, strategic planning is one of a product manager's main responsibilities. Roadmapping goes hand-in-hand with both short- and long-term planning. Product roadmaps help PDMs set achievable goals, conserve limited resources, and share information with the development team and other stakeholders. More than just a list of tasks, the roadmap is a high-level plan that displays the workflow and milestones of a strategy-based pipeline. Some roadmaps are feature-oriented, some are time-boxed, and others are based on quarterly objectives. Here's just one example of a roadmap that is goal-oriented: Prioritize the Feature List and Product Backlog One of the biggest challenges when building a roadmap is deciding what features make the cut. But virtually every highly-successful SaaS business – Github, Slack, Trello – got where they are today by prioritizing new features. Instead of wasting time and money on developing non-essential things, they filled their roadmaps with features that would add genuine value to the product. MoSCoW is one of the most commonly used frameworks for SaaS feature prioritization. So let's break down how it can be applied to the product backlog when building a roadmap. Firstly, MoSCoW is an acronym for Must-have, Should-have, Could-have, and Won't-have. Each of these terms denotes a level of priority from highest to lowest. Must-haves are top-priority requirements. These are features that are essential to product functionality. If we take Uber as an example here, then their 'route mapping' feature counts as a must-have. Should-haves are requirements of secondary priority. These features are considered important but not crucial, e.g., being able to pay via a corporate account in Uber. Could-haves are tweaks that can wait until later in the development timeline for implementation, e.g., a tip jar function in Uber's passenger app. Won't-haves (this time) are features that you still want but can't actually afford under your current budget or deadline. An example might be Uber's ride-scheduling feature, which wouldn't have been essential when the app first launched. Minimum Viable Product In case you haven't heard of this agile product development concept, the minimum viable product (MVP) is a version of your product that contains the fewest features necessary for release to market. A core component of the Lean Startup Model, the MVP allows startups to create a functional product at minimal cost so that they can quickly gather customer feedback and make valuable iterations. We can personally attest to its efficacy because every one of our full-featured products – Mailtrap, Coupler, and Smart above Checklist – began as an MVP. BRIDGeS Framework BRIDGeS is a decision-making and idea-generation framework designed by Railsware. It allows professionals to analyze a problem from various angles, develop targeted solutions, and make a conclusive decision. Sessions can be run either in person (using sticky notes and colored markers) or online with virtual whiteboards (you can try the free Figma template). It takes about 2-8 people to run a productive session. Depending on the issue at hand, attendees may include a product manager and other stakeholders such as software engineers, product designers, marketers, etc. BRIDGeS is an acronym for Benefits, Risks, Issues, Domain Knowledge, Goals, and Solutions. Benefits are what you will gain from a future solution, Issues are your existing problems, Risks are potential issues you might face, Domain Knowledge is information that helps provide context, and Goals are what you hope to get from the future solution. Each type can be added to the board using a different colored card. Here's an example of what the Problem Space looks like after a problem has been broken down using these descriptors. We've used the Uber example again here. In this example, each task has already been prioritized using the MoSCoW method we discussed earlier. So, it is time to move into the Solution Space. This is where we ideate solution variations based on the identified benefits, risks, and issues. We then describe the chosen solution through epics and nested tasks, which can actually be transformed into a product roadmap. Lean Canvas Designed by Ash Maurya, Lean Canvas is a tool for checking the viability of your product idea. It's considered an alternative to the traditional business plan and an adaptation of the Business Model Canvas (the brainchild of Alexander Osterwalder). The purpose of Lean Canvas is to help product managers and startup founders analyze the strengths and weaknesses of their business model and mitigate the risks associated with launching a new product into a competitive and fast-changing market. However, for existing and well-established businesses, the Business Model Canvas is generally the preferred choice. In practical terms, Lean Canvas is a single-page document that consists of nine boxes to be filled in. Their headings are Customer Segments, Problems, Revenue Streams, Solutions, Unique Value Propositions, Channels, Key Metrics, Cost Structure, and Unfair Advantage. Each section allows you to focus on a different aspect of your product offering and structure, to ensure all bases are covered, and the spotlight remains on customer needs. Value Proposition Canvas Created by Strategyzer, Value Proposition Canvas is a tool to help product managers and startup founders get closer to a product-market fit. It can help you understand your customers' needs and pains, find new ways to drive user engagement, and refine your brand messaging and marketing strategy. The canvas is divided into two parts; traditionally, a square on the left (Value Proposition segment) and a circle on the right (Customer segment). Here's a visualization: When filling out the canvas, you begin in the customer segment by listing the customer's jobs, pains, and gains. This part helps you define the tasks customers are expected to execute and any negative or positive experiences they might have while doing them. Then you move on to the left side, where you will deal with the product. Here you will break down products and services, pain relievers, and gain creators related to your product offering. Essentially, these are the benefits (or unique value) that your solution offers to customers. After completing the canvas, you should have a strong idea of how to differentiate your product from others on the market and communicate that unique value to your target audience. Software that Helps Manage SaaS Products Here are some applications and tools that our product managers use to plan new projects, manage their daily workloads, collaborate with teammates, and connect with customers: Figma: For collaborating with designers, wireframing, creating interactive prototypes, and sketching ideas/brainstorming. Slack: For seamless communication with teammates and stakeholders. Google Sheets: For product planning activities and organizing market research/customer data. Looker Studio: For creating free product dashboards and visualizing different aspects of product performance (customer success, ad campaigns, sales leads). Coupler.io: For automating data flows between apps such as Airtable or Pipedrive and destinations like GSheets, Big Query, and Microsoft Excel. Notion or Coda: For knowledge storing, project management, and note taking during collaborations. Typeform: For creating engaging customer surveys. Google Meets and Calendly: For client calls, conducting customer interviews, and meetings with C-suite executives. Now let's dive into something a little different. This next part is for startup founders who are ready to hire a product manager for their team. How to Hire a Good Product Manager Here we'll share our process for hiring product managers who are hands-on, t-shaped, and lead by example. So, in addition to all of the key skills we discussed earlier, there are several others we look for during the candidate screening and selection process. Strong communication skills are a must, of course, since product managers will be working closely with people from all corners of the product and company, as are strong organizational skills since the role involves juggling meetings, research, leadership duties, and so on. Meanwhile, being attentive to details, curious about how the product works, and having a good memory are also highly desirable traits, though not always dealbreakers. Here are a couple of other things we take into consideration: Technical Background In our experience, product managers with technical backgrounds (think computer science or data analysis) are better equipped for the role than those with experience strictly in product design, sales, or marketing. Knowing how to code, how to break down/organize data, and how to spot bottlenecks in development pipelines are highly-coveted skills. Real-World Experience We aren't really interested in management degrees. Instead, we strive to hire PDMs who have experience managing real-world products, preferably in the SaaS space. In addition, they must be able to critically discuss their past experiences and demonstrate a history of problem-solving, decision-making, and true leadership. Resources for Product Managers There are no shortcuts to launching a career in product management or becoming an expert in the field. Unfortunately, no single resource — book, course, podcast — can teach you everything you need to know about the discipline. However, based on recommendations from our product managers, here are some useful materials to help you grasp the essentials. The Lean Startup Already a modern classic, The Lean Startup by Eric Ries is a must-read for product managers working in the SaaS space. It covers the MVP concept in depth and explains how to leverage the ever-popular Lean Startup framework. INSPIRED: How to Create Tech Products Customers Love INSPIRED goes much deeper into some of the topics we've covered here, including the skills product managers need and what processes they should follow. It's suitable for PDMs working at all stages of the product lifecycle, from introduction to maturity and beyond. The Mom Test: How to talk to Customers and Learn if Your Business Is a Good Idea When Everyone Is Lying to You Despite its odd name, The Mom Test is considered one of the top manuals on how to effectively validate your business idea. It explains how to go about the customer development process the right way and extract meaningful insights from your target audience. A note on Mentorship: "If you’re a software engineer, data analyst, or QA and you’re interested in becoming a product manager, the best advice I can give is to find a mentor. Contact a PDM within your current company who is an expert at their craft, set up a meeting, and see if they can help you evaluate the best path forward. This is a great way to find out if the role is really for you." - Yevgen Tsvetukhin (Product Manager) Wrapping Up On a closing note, we asked a couple of our product managers what their favorite and least favorite parts of the job are. Here's what they had to say: "Experimenting is the most exciting part of SaaS product development. By making small changes to the product and properly measuring the results, you can test lots of hypotheses in a real-life environment. On the other hand, the hardest part is having to make unbiased decisions. You don’t always have tons of data to support your position, and you are dealing with stakeholders who, as all humans, have their personal preferences." - Julia Romanenkova (Product Lead) "For me, the most rewarding part of product management is getting to see how your product benefits customers. However, the hardest part is all of the work that comes after the product launch, and before its success. It takes more than an MVP to start seeing that impact." - Julia Ryzhkova (Product Lead) Product managers are strategists. They create data-driven action plans and bring structure to a founder's vision and unity to the contributions of cross-functional teams. In our view, every SaaS company needs designated experts who can answer tough questions and steer a new product along the path to success.
Keeping on top of your project management tasks can be a daunting task, but with the right database and system in place, it’s easier than you think! In this blog article, we’ll take a look at why it’s so important to maintain an effective project management database and how to get started. What Is a Project Management Database? A project management database is a crucial tool for any organization looking to stay organized and on track with their projects. It is an essential part of any project management system and is used to store and access important information related to the project. This information can include task lists, milestones, deadlines, resources, budgets, and more. A project management database ensures that all data related to a project is kept up-to-date and easily accessible. Having this data in one central location makes it easier for everyone involved in the project to access and use the information they need. With a project management database, teams can easily keep track of progress, assign tasks, manage resources, and set deadlines. It also allows teams to monitor budgets and view reports in real time. This helps ensure that projects are completed on time and within budget. Furthermore, with a project management database, organizations can gain insights into how their projects are performing over time so they can make necessary adjustments as needed. In conclusion, a project management database is an invaluable tool for any organization looking to streamline its operations and remain organized. It provides teams with the necessary tools they need to manage projects effectively while also providing them with powerful insights into how their projects are performing over time. Why Is It Important to Maintain a Project Management Database? Maintaining a project management database is essential for the successful completion of any project. It provides an organized system for tracking and managing key components of the project, including tasks, deadlines, resources, costs, risks, and more. By having a single source of data that can be easily accessed and updated by all team members, organizations are able to optimize their workflow and ensure that projects are completed on time and within budget. A project management database also allows for better communication between teams. Instead of relying on emails or other unreliable methods of communication, teams can access up-to-date information through the centralized database. This allows team members to quickly identify any changes or adjustments that need to be made in order to stay on track. Furthermore, a project management database provides valuable insights into the progress of a project. With detailed reports and analytics available at your fingertips, it’s easy to track milestones, pinpoint areas where improvement is needed, and identify potential issues before they become bigger problems down the road. In short, maintaining a project management database is an essential part of staying organized and ensuring that projects are completed on time and within budget. What Is a Work Breakdown Structure in Project Management? A work breakdown structure (WBS) is an essential element of project management. It is used to break down a project into smaller, more manageable tasks. By breaking down a project into a hierarchical structure of discrete activities, the WBS provides an organized view of the project and its components. This allows for better planning and control throughout the lifetime of the project. At its core, the WBS is a visual representation of the tasks and subtasks involved in completing a project. It consists of activities broken down by level, with each level providing more detail about the task at hand. The highest-level activities are usually referred to as “phases,” while lower-level activities are called “tasks” or “subtasks.” The WBS helps to identify any gaps between the tasks required to complete a project and makes it easier to assign resources accordingly. A well-crafted WBS can be used as part of an effective project management database that helps track progress, costs, resources, risks, and more. A good WBS will also help you estimate costs more accurately by breaking tasks down into their individual elements. This allows for better budgeting and cost control during each phase of the project lifecycle. Benefits of Maintaining a Project Management Database A. Improved Organization The organization is the key to success in any project, and maintaining a project management database can help ensure that all aspects of a project stay organized. By centralizing information in one place, it’s easier to keep track of tasks, deadlines, resources, and other important details. This helps teams work together efficiently and ensures that nothing falls through the cracks. With an up-to-date project management database, teams have access to all the necessary information they need to stay on top of their projects and meet goals in a timely manner. Furthermore, this information can be shared with stakeholders outside the team so they can monitor progress without having to ask for updates. A project management database is an invaluable tool for staying organized and on track with projects! B. Increased Visibility and Accountability Having a project management database is essential for any organization that wants to ensure the success of its projects. A project management database allows teams to track progress and hold everyone accountable for their tasks. By having a database in place, teams can easily access data and view performance metrics at a glance. This increased visibility helps organizations stay on top of their projects and make informed decisions quickly. Not only does a project management database provide increased visibility, but it also creates a culture of accountability within an organization. With the data available, team members can easily see what tasks are assigned to them and measure their performance against set goals. This helps create an environment where each team member takes ownership of their role, ensuring that projects are completed on time and within budget. To summarize, maintaining a project management database is essential for any organization striving for success. It provides increased visibility into performance metrics so teams can make informed decisions quickly, as well as creates an environment of accountability where team members take ownership of their role in completing projects. C. Improved Collaboration Having a project management database in place is essential to ensure successful collaboration between teams. A project management database allows all team members to access up-to-date information related to the project, streamlining communication and facilitating better decision-making. This is especially important for large projects that involve multiple teams and stakeholders. The improved collaboration enabled by a project management database also helps to reduce confusion among team members, which can significantly improve the efficiency of the project. By having a single source of truth about the project, each team member can quickly access the relevant details needed to complete their assigned tasks. This eliminates the need for redundant updates or conversations, allowing team members to focus on the tasks at hand. Finally, a project management database also makes it easier for multiple teams to work together effectively by providing an easy way to exchange information and track progress against milestones. This allows stakeholders from different departments or organizations to easily view progress on shared goals, ensuring everyone is on the same page with regard to deadlines and expectations. Types of Project Management Databases A. Spreadsheets Spreadsheets are one of the most popular ways to maintain a project management database. This is because they are easy to set up, contain all the necessary information, and can be quickly modified. Spreadsheets allow you to easily organize data into categories, track progress, and provide an overview of a project’s status. They also offer a range of features such as drag-and-drop sorting, conditional formatting, and pivot tables. Using spreadsheets as your project management database provides many advantages. First, they give you an organized view of your project’s data and enable better decision-making. By categorizing data into distinct columns you can quickly identify key trends or issues in the project and adjust your strategy accordingly. Additionally, the ability to apply various formulas or functions makes it easier to draw insights from complex data sets. Finally, spreadsheets are highly customizable and can be tailored to meet specific requirements or scale with growing needs. This means that regardless of whether your project is small or large, you can always find a way to make it work within spreadsheet parameters. B. Online Project Management Software Project management databases are essential for any organization looking to keep its projects organized and running smoothly. Online project planning software is a great way to manage projects of all sizes, whether it’s a small task or a large-scale project. This type of software helps manage tasks, resources, timelines, budgets, and more. It also allows teams to collaborate with each other in real time from any location. Online project management software provides an intuitive interface that makes it easy for users to create and assign tasks, as well as track progress. This type of software also offers features like task notifications, priority settings, file-sharing capabilities, milestone tracking, timeline views, and more. Additionally, many online project management tools provide analytical features to help teams track their success over time and make informed decisions about future projects. Using online project management software can help streamline the workflow process by enabling efficient collaboration between team members. This allows teams to stay on top of progress and deadlines without having to manually enter information or sift through emails looking for updates from each team member. C. Customized Solutions When it comes to project management, having a reliable database is essential. A customized project management database can make all the difference in the success of your projects. Not only do they provide you with a way to store and access data quickly and easily, but they also allow you to tailor the system to meet your specific needs. Customized solutions offer a variety of advantages over traditional solutions. For starters, they allow you to customize the system in order to suit your exact requirements. This means that you can add or remove features as needed, allowing you to tailor the system so that it best serves your project’s needs. Furthermore, customized solutions often come with additional features that may not be available in traditional solutions, such as workflow automation, advanced reporting capabilities, or integrated analytics tools. Another benefit of using customized solutions for project management databases is the improved security. With these systems in place, you can ensure that sensitive data is kept secure from unauthorized access and tampering. Additionally, customized systems typically offer more robust backup and recovery options than traditional solutions, giving you peace of mind should anything go wrong with your database. How to Create a Project Management Database A. Gather Requirements Having a project management database is an essential tool for any successful project. It allows you to track and monitor the progress of the project, ensure that tasks are completed on time, and keep all project-related information organized. However, in order to create a successful project management database, it is important to begin by gathering requirements. The first step in gathering requirements for a project management database is to identify the purpose of the database. What will it be used for? Who will be using it? Knowing these answers will help you determine what features and capabilities your database needs in order to meet those needs. Once you know the purpose of your database, the next step is to determine what data needs to be stored in the system. This includes not only the type of data that needs to be stored but also its format and structure. For example, if you need to store customer information, then you should determine what fields are needed such as customer name, address, contact information, etc., as well as how this data should be structured within the system. B. Choose the Right Software or Platform When it comes to choosing the right software or platform for your project management database, it’s important to consider your specific needs and the goals of your project. Depending on the scope of the project, you may need to choose a more comprehensive solution than what is available from basic software programs. There are a variety of solutions available for creating and managing a project management database. Some popular options include Microsoft Excel, Access, and SharePoint. Each has its own merits and drawbacks that should be considered when making a selection. Microsoft Excel is one of the most popular platforms for creating a project management database due to its flexibility and ease of use. It can be used to create simple spreadsheets or more complex models depending on the user’s needs. However, it does not have many built-in features specifically designed for managing projects and can be difficult to use with large datasets. C. Document Your Processes Organizing and tracking projects can become a daunting task for any organization. To ensure consistency and accuracy, it is important to document processes and store them in a project management database. A project management database provides a centralized repository for all project data, enabling teams to quickly access the information they need. Having an organized and up-to-date project management database is essential for successful project delivery. It allows teams to easily access relevant documents, track progress, identify roadblocks, and make informed decisions. A well-maintained database also helps streamline communication and collaboration between team members. Creating a project management database involves several steps. First, define the scope of the project by considering who will be using the system and what data needs to be collected throughout the process. Once the scope of the project is determined, create a list of objects that should be stored in the system (e.g., contacts, tasks, milestones). Then, decide on how data should be structured within each object (e.g., fields, tables). Finally, establish rules for data entry (e.g., naming conventions) and make sure that everyone on the team is familiar with them. D. Train Your Team Proper training is essential for any successful project management database. Without the right knowledge and skill set, it can be difficult to effectively maintain and use a project management database. To ensure your team is well-equipped to manage and use the database, it’s important to provide them with training on its features and functionality. The first step in training your team is to provide an overview of the project management system. Make sure they understand the purpose of the system, how it works, and how they can use it to their advantage. You should also explain any specific tools or features that are available such as reporting functions or workflow automation. Once your team has a basic understanding of the system, you can move on to more advanced topics like data entry protocols, query-building techniques, and report design principles. It’s also important to cover any security measures that are in place so that your team knows how to protect sensitive information from unauthorized access. Conclusion In conclusion, maintaining a project management database is essential for any organization that wants to successfully manage its projects. It provides an efficient way to store and access project data and allows teams to collaborate more effectively. Additionally, it allows organizations to track progress, identify issues, and ensure projects remain on schedule. A strong project management database helps ensure that all goals are met in a timely manner while also providing the necessary information needed for accurate reporting.
Author, Researcher, Speaker, Director, DevOps Enthusiast,
Founder and CEO,
Software Engineer and Architect and Open Source Committer,
VP of Engineering,
Names and Faces