What is SOC2? 

SOC2 is designed to ensure that you securely manage your data to protect both your organization’s interests and your clients’ privacy. It’s particularly relevant for businesses that use cloud technology to store customer information, making it a really useful benchmark for SaaS companies and cloud vendors alike​​​​.

The SOC2 framework is structured around five Trust Service Criteria (TSC): Security, Availability, Processing Integrity, Confidentiality, and Privacy. Each of these criteria addresses a different aspect of operational security and data management:

In this article, I’ll take you through:

• Why SOC2 compliance is important
• The three main components of SOC2
• Why it’s a useful starting point for your compliance journey
• How to become SOC2 compliant

What makes SOC2 compliance so important?

Essentially, SOC2 is all about safeguarding data and building trust. If you’re handling sensitive information (and let’s face it, pretty much all information is sensitive these days), achieving SOC2 compliance isn’t just about meeting a regulatory benchmark. It’s a clear way to demonstrate that your company is serious about security.

Given how concerns over data privacy are escalating, being SOC2 compliant can provide you with a competitive edge. It shows you’re a trustworthy and secure partner to work with. This is getting more and more important, especially as potential enterprise customers and partners often require SOC2 compliance as a prerequisite for engagement​​​​.

Something that makes SOC2 stand out is its adaptability – you’re not required to meet all five of the criteria it’s judged on, but can choose those relevant to your business operations and objectives. This flexibility lets you tailor your compliance efforts to what’s applicable to your product, rather than adopting a less efficient one-size-fits-all approach​​.

SOC2 also allows you to design your controls to meet the particular TSC requirements that you pick, unlike other compliance standards that offer a prescriptive list of controls. This customizability makes SOC2 a versatile and appealing option, especially for those of us working with SaaS and cloud services.

SOC2 compliance is a big win for any organization that stores or processes customer data. By adhering to the SOC2 framework and achieving compliance, you’ll both protect your clients and your business from data breaches and cyber threats, and also enhance your marketability, and build stronger trust with your customers and partners.

Trust Service Criteria, controls, and evidence: the pillars of SOC2 compliance

The Trust Service Criteria (TSC), controls, and evidence are the bones of SOC2’s framework. This framework helps you prove that your company is dedicated to protecting customer data through a structured and transparent approach.

What are the Trust Service Criteria (TSC)?

The TSC are a set of principles that underpin SOC2 compliance, providing a comprehensive blueprint for organizations to manage customer data securely and responsibly.

By adhering to these criteria, you can align your practices with best-in-class security standards, protecting sensitive information from being spread.

The five TSC are:

• Security: Serves as the baseline criterion, emphasizing the need for robust access controls, firewalls, intrusion detection, and other preventative measures to safeguard system resources.  It’s the only mandatory principle, underscoring its importance in the SOC2 framework.
• Availability: Targets the reliability of services, requiring systems to be accessible and operational for users as agreed upon in SLAs or contracts.
• Processing Integrity: Focuses on ensuring that system processing is accurate, timely, complete, and authorized, underpinning the reliability of operational processes.
• Confidentiality: This concerns the protection of confidential information from unauthorized access and disclosures, applying primarily to data that is restricted to certain users or organizations.
• Privacy: Relates to the handling of personal information in accordance with the company’s privacy notice and applicable privacy regulations, ensuring the ethical management of personal data​​​​.

What role do controls play in SOC2 compliance?

Controls are the specific practices and policies that are put in place to meet your chosen TSC. They are the mechanisms you use to put those criteria in operation, and cover everything from meatspace security measures to digital safeguards and procedural protocols.

Your controls will need to be designed around the unique risks and operational environment that you’re working with, and the specific TSC you’re aiming to comply with. Using this bespoke approach will let you address your specific security and compliance needs more efficiently and effectively, and help to embed SOC2 principles into your operational DNA​​​​.

Examples of SOC2 controls

Here are a few examples of the sort of controls you might need to implement: 

• multi-factor authentication for system access
• encryption of data in transit and at rest
• regular vulnerability assessments
• employee training programs on data protection

How do you use evidence to demonstrate your SOC2 compliance?

There’s no point going through all that hard work and not having anything to show for it. That’s why evidence collection is such a critical component of the SOC2 compliance process – you must document and demonstrate the effectiveness of your controls.

This involves gathering, organizing, and presenting data that proves that you’re adhering to the TSC through the controls you’ve implemented. It plays a crucial role during the final SOC2 audit, as the auditors will review this evidence to assess the organization’s compliance with the selected TSC​​​​.

Examples of SOC2 evidence

The evidence you’ll need to gather for your SOC2 audit includes things like:

• policy documents
• system logs
• audit trails
• incident response records
• employee training records

Collecting and managing your evidence is an ongoing process. You need to continuously monitor and adjust your controls as the playing field changes. After all, hackers never stop iterating, so neither can you.

Why is SOC2 a good place to start?

Thanks to its flexibility compared to other compliance standards, SOC2 is a particularly good fit if you’re at the start of your business’ compliance journey, especially for startups and smaller companies. By letting you choose specific TSC that match your needs, it gives you a tailored compliance path that will align more closely with your company’s risk profile and operational priorities.

The initial focus on the mandatory Security criterion gives you a solid foundation to build from, and lets you add to it when you need to and are ready to. It accommodates business growth, allowing you to phase your compliance process, and provides scalability. This is really useful for rapidly evolving startups and smaller businesses, providing a baseline to build upon with additional compliance layers as they grow.

Compared to more prescriptive standards like ISO27017 and ISO27018, SOC2’s less stringent approach gives room for greater innovation and agility in meeting the compliance requirements, so you’ll have the freedom to design controls that fit how your business and product work.

SOC2’s model encourages a customized, scalable approach to compliance, focusing on security while enabling you to adapt and evolve your compliance strategy as your business grows. Embracing its adaptable framework, will help you make sure that you’re on top of security and privacy now, and in the future.

When you’re ready to start thinking about your next compliance goals after SOC2, be sure to check out my full guide on enterprise-ready compliance.

How do you achieve SOC2 compliance?

The journey to SOC2 compliance is a thorough process, to say the least! There are a bunch of critical steps that you’ll want to get prepared for, from the initial selection of Trust Service Criteria (TSC) to the final audit.

By the end of this pathway, you’ll not only meet the stringent requirements set forth by SOC2, but you’ll also enjoy enhanced overall security and operational integrity.

This isn’t the sexiest initiative on your roadmap, nor will it be the most fun you’ve ever had at work, but by heck you’ll feel like celebrating when it’s done and you have that compliance badge in your hand. 

So, let’s kick off and explore these steps in detail, highlighting where you, as a product leader, can help your teams navigate this complex landscape.

1. Select your Trust Service Criteria and controls

The first step involves deciding which of the TSC you want to be included in the SOC2 audit. This decision defines the scope of your compliance efforts and helps you ensure that you’ve focused on the areas that are most relevant to your business and your customer expectations.

As a Product leader, you will play a key role here, as it’s your job to make sure the selected criteria align with the product’s security needs and business objectives​​. You’ll need to work closely with a range of internal stakeholders, including security teams and executive management, to identify which TSC fits your needs.

After selecting the relevant TSC, the next stage of the process is designing and implementing controls that meet the criteria. It takes a deep understanding of your product’s architecture and operational workflows to get this stage right, as well as a strategic approach to embedding security into these processes​​​​.

2. Producing a Gap Analysis Report

Next, you should conduct a comprehensive gap analysis to compare your current security practices against the SOC2 requirements. This report will highlight where you’re non-compliant, and lays out a framework for addressing these gaps.

You need to make sure that the gap analysis covers all aspects of your product, infrastructure, and company operations, so it can give you a clear picture of the steps you’ll have to take to achieve compliance.

Make sure to engage teams from across the business when reviewing your report. That way you’ll ensure you’re covering all perspectives when you work out what to do about it. The report should offer actionable insights, so you can prioritize your compliance efforts based on risk, impact, and resource availability.

3. Implement the changes

Based on what you discover with your gap analysis, the real work starts, because it’s time to get busy implementing the necessary changes to your policies, procedures, and tech. This can often be the hardest part of the whole process, as you’ll likely find you need to make some pretty significant modifications to how you do things, and your product itself.

It’s also your time to shine, because you’ll be coordinating the changes across all the affected teams. It’s up to you to make sure that everyone’s work aligns with the SOC2 requirements, and doesn’t disrupt the product’s functionality or user experience​​.

This is your initiative to manage, with a clear schedule, responsibilities, and milestones to guide the implementation process. You’ll want to help and encourage your departments to collaborate, because the changes have to be implemented cohesively across the whole company.

4. Collect your evidence and prepare for the audit

As you are making the necessary changes, it’s vital you start collecting the evidence you’ll need to prove your compliance with the selected TSC and controls. Simply put, there’s no point in doing the work if you can’t show what you’ve done.

Your evidence will be reviewed by the auditors to assess the company’s adherence to SOC2 standards. You need to ensure that evidence is being collected systematically and comprehensively, and that it covers all aspects of the changes​​​​ you’ve implemented.

Having detailed documentation of all the changes made, including your policies, procedures, and system configurations, is essential for your evidence-collection process. You’ll probably find it helpful to regularly review and update your evidence collection process as you go to ensure that all the necessary documentation stays accurate and up-to-date.

5. Audit

The final step in the SOC2 compliance journey is the audit, conducted by an AICPA-certified auditor. They will assess how effective your controls are and the accuracy of the evidence you’ve provided. You’ll want to work closely with the auditors, giving them access to any information they need and deal with any questions or concerns that may crop up during the audit process​​​​.

Giving your support to the auditors, including providing them with clarifications and any additional documentation they need, is key to a successful audit. Plus, after the audit, you should review their findings and implement any recommended improvements.

What are the two types of SOC2 reports?

Using everything I’ve told you so far, you should be able to lay a solid and comprehensive foundation for your journey to SOC2 compliance. And at the end of that journey is the all-important final milestone: your SOC2 report.

This report is a testament to your company’s adherence to the stringent standards set by the AICPA on security, privacy, and data protection. Again, though, SOC adds flexibility to the process by offering two types of SOC2 reports at differing levels of rigor – Type 1 and Type 2. 

SOC2 Type 1 report

The SOC2 Type 1 report (also written as Type I) is often seen as the first stage in the SOC2 compliance journey. It provides a snapshot of your organization’s commitment to security and operational integrity.

This report demonstrates your company’s capability to design systems and controls that effectively meet your chosen TSC. It can serve as a powerful tool in the earlier stages of product development or market entry, as it offers reassurance to your stakeholders and customers that you take security seriously.

Gathering and presenting evidence required for a Type 1 report still requires meticulous documentation of how you design your systems and controls, so it will still take thorough planning and organization​​​​.

SOC2 Type 2 report

The SOC2 Type 2 report (also written as Type II) goes a step further, as it evaluates the operational effectiveness of those systems and controls over a period of time. This type of report provides a more comprehensive view of how the controls are implemented and function in your daily operations.

It’s a more robust demonstration of your company’s commitment to maintaining high standards of security and privacy, as it shows you can design, effectively implement, and maintain controls that will protect your customer data over time.

Achieving a Type 2 report takes continuous effort, monitoring, adjusting, and documenting the operational effectiveness of your controls, so you’ll really have to commit to constantly updating and improving to maintain compliance.

Example of a SOC2 Type 2 report

If you’re wondering what the eventual report will look like, why not take a look at ours here at ProdPad. You can find details about our SOC2 compliance in our Trust Center and download a copy of the Type 2 report.  

How can product leaders help guide the SOC2 compliance process?

For product leaders, getting to grips with SOC2 reports is more than ticking boxes—it’s a strategic journey. Here’s how to tackle it:

Coordination is key: It’s crucial to bring teams from Security, Operations, and Product Development together. As a product leader, you’re the linchpin in this effort, working to build a culture where compliance and security are everyone’s business.

Strategize for success: Aligning your SOC2 compliance with your business goals is essential. Think of it as steering your compliance efforts in a way that fuels innovation and growth, rather than holding them back.

Turn compliance into opportunity: Getting your SOC2 reports isn’t just about meeting standards; it’s a chance to stand out. Use it to underscore your commitment to security and privacy. This is a powerful message for your customers and a solid foundation for growth.

Successfully jumping through all the hoops to get your SOC2 reports, whether Type 1 or Type 2, is a clear signal of your commitment to the highest security and privacy standards. These aren’t just shiny badges to collect. They’re tools that can enhance your product’s appeal, build customer trust, and drive your company forward.

By being smart about how you navigate the SOC2 compliance path, and by making the most of the knowledge the reports can give you, you’re not just securing your data (important as that is!). You’re securing a competitive edge in a world that values security more than ever.

The post SOC2 Compliance: A Product Leader’s Guide to Getting It appeared first on ProdPad.

What compliance certifications do you need to be enterprise-ready?

To be enterprise-ready, software companies need to adhere to a wide range of compliance certifications, each serving different aspects of software security, data protection, and operational integrity. The specific industry and where you’re operating also matters, with requirements differing from country to country, and even at the state level in the US.

Different industries will also have different compliance requirements, and the necessity for those certifications will differ depending on whether the industry is a regulated one or not.
Here’s a look at some of the crucial certifications, ranked by their importance, to guide your compliance journey.

Must have certifications to be enterprise-ready

These certifications are the ones most commonly on enterprise procurement teams’ must-have list. It’s very unlikely you’d find enterprise organizations that would buy a software tool that didn’t comply with most of these standards.

• ISO/IEC 27001 – A global standard for information security management systems (ISMS), crucial for protecting your systems from security threats.
• SOC 2 – Ideal for service providers storing customer data in the cloud, it ensures your information security measures are in line with industry standards.
• GDPR compliance – For companies operating in or serving customers in the EU, adherence to the General Data Protection Regulation is mandatory for data protection and privacy.
• ISO/IEC 27017 – Pertaining to cloud security, an important standard for organizations operating in the cloud, providing guidelines on information security controls.
• ISO/IEC 27018 – This standard is vital for cloud service providers handling personal data.

Important international certifications to be enterprise-ready

Depending on where you are operating, the following certifications could be highly important to your organization’s certification process.

• Cyber Essentials – A UK government-backed scheme that provides a foundation of cybersecurity measures for all industries.
• CCPA compliance – For companies operating in California, the California Consumer Privacy Act sets a benchmark for privacy and data protection.
• EUCC – For European companies, following the European Union Agency for Cybersecurity guidelines helps align with EU standards for network and information security.

Important industry-specific certifications to be enterprise-ready

If your product serves more highly regulated industries, such as the Healthcare or Financial sectors, or you work with government agencies, then there will be some very specific certifications that you will need to achieve.

• HIPAA – For software companies in the healthcare sector, complying with the Health Insurance Portability and Accountability Act is crucial for protecting patient data.
• PCI DSS – If you handle credit card transactions, the Payment Card Industry Data Security Standard is a must-have for securing payment information.
• FISMA – The Federal Information Security Management Act is important for companies working with US federal agencies to ensure data security and privacy.
• FedRAMP – Mandatory for cloud service providers serving US federal agencies, ensuring cloud products and services are secure.
• HITRUST CSF – In healthcare, HITRUST certification combines HIPAA requirements with other standards, providing comprehensive security and privacy measures.

Good-to-have certifications to be enterprise-ready

While these certifications are less vital to have, they can be both important hygiene factors for your business, and useful differentiators in a crowded or competitive market.

• ISO/IEC 27701 – As an extension to ISO/IEC 27001, focusing on privacy information management, it’s beneficial for enhancing privacy protocols beyond the basics.
• NIST Cybersecurity Framework – While not strictly speaking a certification, adhering to the NIST guidelines can significantly bolster your cybersecurity posture and is highly regarded in the industry.
• CMMC – The Cybersecurity Maturity Model Certification is becoming increasingly important for companies in the defense industrial base but is not universally required.
• ISO 22301 – Business continuity management, ensuring your business can continue operating during disruptions.
• ISO/IEC 20000 – IT service management, showing commitment to quality of service and customer satisfaction.
• CSA STAR certification – The Security Trust Assurance and Risk (STAR) Program for cloud environments, integrating key principles of transparency and trust.

Prioritizing your enterprise-ready compliance efforts

What is a priority for you largely depends on your industry, the nature of the data you handle, and the markets your product serves. For most software companies, starting with ISO/IEC 27001 and SOC 2 certifications is a smart move, as they lay a solid foundation for information security management and operational integrity. GDPR and PCI DSS become critical based on geographic operation and transaction handling, respectively.

HIPAA and FISMA are indispensable for those in healthcare and government contracting, while ISO/IEC 27701 and the NIST Cybersecurity Framework are excellent for bolstering your security and privacy measures further. Industry-specific certifications like FedRAMP and HITRUST CSF should be pursued based on the specific market segments you are targeting.

The landscape of compliance certifications can seem complex (and it is!), but focusing on the “must-haves” first will allow you to build a robust compliance framework. From there, adding “good-to-haves” and industry- and location-specific certifications can enhance your competitive edge and help you ensure that your software is enterprise-ready for customers worldwide.

Who should be responsible for achieving enterprise-ready compliance?

Achieving enterprise-ready compliance is a multifarious endeavor that will require coordination and collaboration across several roles within your organization. The Product Manager often takes the day-to-day lead in navigating the compliance landscape. However, your efforts need to be supported and complemented by a diverse and cross-functional team, each contributing their expertise to ensure comprehensive compliance.

Product Managers are at the forefront, responsible for overseeing the product’s strategy and roadmap, and ensuring that compliance requirements are prioritized appropriately and given the right strategic importance. As a PM, you coordinate with various departments, translate legal requirements into technical specifications, and monitor the progress toward compliance goals.

IT and Security Teams are the people you’ll need to implement the technical aspects of compliance. This includes securing data, managing cybersecurity risks, ensuring the integrity of information systems, and deploying necessary infrastructure upgrades. Their expertise is central to addressing the technical requirements of various compliance standards.

Legal Advisors can clue you in on the important details relating to the legal implications of your compliance decisions. They’ll help you navigate the complexities of international laws and regulations to ensure you’re enterprise-ready. They assist in contract management, intellectual property issues, and ensuring that all aspects of your product and its development adhere to applicable laws.

Human Resources (HR) also plays a vital role, especially in ensuring compliance with regulations related to employee data and privacy. You’ll need these folks training everyone on compliance-related matters, managing personnel records in compliance with legal standards, and ensuring that company policies reflect the latest regulatory requirements.

If you can bring these teams together and get everyone working in harmony, you’ll have formed yourself a compliance A-Team, each bringing their own unique perspective and expertise to ensure your plan comes together.

If you collaborate in this way, you’ll not only ensure that your products meet the necessary compliance standards, but you’ll also help to foster a culture of compliance and ethical behavior within the organization.

What are the steps for getting enterprise-ready?

To get your software enterprise-ready, we’ve compiled a structured path you can follow – it involves detailed planning, rigorous testing, and continuous improvement.

Here’s a step-by-step guide showing you what you need to do to achieve compliance and prepare your software for enterprise customers:

1. Conduct a gap analysis

Start with an in-depth audit of your current software against the compliance standards you aim to meet. This involves evaluating your software’s security features, data handling processes, and operational procedures.

Tools and frameworks like the NIST Cybersecurity Framework can be useful here. The outcome is a Gap Report that highlights discrepancies between your current state and the compliance requirements.

2. Develop a strategic compliance plan

Based on the Gap Report, craft a detailed plan that outlines the necessary actions to bridge the compliance gaps. This plan should include:

• Software adjustments: Specify the changes needed in your software’s architecture, coding practices, and features to enhance security and privacy.
• Infrastructure upgrades: Detail the infrastructural improvements required, such as server security enhancements and secure data storage solutions.
• Policy and procedural updates: Outline the revisions needed in your internal policies and procedures to align with compliance standards. This includes training programs for staff on compliance best practices.

It’s a good idea to make sure your compliance plan has its rightful place on your roadmap rather than being squeezed in as someone’s side project. After all, if it’s strategically important that you make in-roads in the enterprise market, then that importance needs to be reflected in your product priorities. That will help ensure the initiative is given the right level of resource and investment.

If done right, compliance to these standards should unlock sales opportunities and directly impact revenue. That’s why you need to get this on your roadmap, set a nice target outcome of increasing revenue or growing enterprise market share – and then measure the results post-release and celebrate the wins!

3. Implement the compliance measures

With the plan in place, start putting it into practice. This step is iterative and involves:

• Software development: Update your software according to the plan, incorporating enhanced security features and compliance-specific functionalities.
• Infrastructure modifications: Upgrade your IT infrastructure to support the necessary security and compliance measures.
• Policy enforcement: Update your internal policies and procedures, and ensure all staff are trained and aware of their responsibilities under the new guidelines.

4. Conduct internal audits and pre-certification assessments

Before seeking official certification, conduct thorough internal audits to test the effectiveness of your enterprise-ready compliance measures. This might involve simulated security breaches, data privacy audits, and other stress tests.

Pre-certification assessments by third-party organizations can also offer valuable insights and identify any remaining gaps before you apply for certification.

5. Obtain official certification

Once you’re confident in your compliance status, it’s time to obtain your official certification from the relevant authorities. This process will vary depending on the specific certifications you’re pursuing but generally involves extensive documentation and an official audit by the certifying body.

There are companies you could call on to help you manage this stage of getting enterprise-ready. Organizations such as Trust Assurance Platform, Vanta, Drata, or Strikegraph can help you gather all the evidence and documentation that you need to present to the auditors. Known as compliance platforms, these tools and services can help you speed up the process and get you over the final hurdle.

These platforms can be used to automatically collect (where the integration exists) the evidence needed to prove you meet the controls on a regular basis. In addition, these platforms allow you to upload evidence manually again on a regular basis. This way the auditors can review the evidence without needing to talk to you directly.

6. Implement continuous monitoring and improvement

You’re not done yet! Compliance is not a one-off achievement but an ongoing process. Implement systems for continuous monitoring of your compliance status, including regular software updates, periodic audits, and ongoing staff training.

Stay informed about changes in compliance standards and adjust your practices accordingly to maintain your certifications. Don’t take your eye off the compliance ball! 

7. Customer transparency and support

Finally, ensure that your efforts toward compliance are visible and transparent to your customers. Provide them with detailed information about your compliance status and how it protects their data and interests. This is a good news story and it’s worth shouting about.

Offer support for any compliance-related queries they may have, and demonstrate how your software facilitates their own compliance efforts, such as through audit trails, security features, and data management tools.

8. Secure new enterprise customers!

Don’t go through all the work to get your compliance badges and then not shout it from the rooftops! The whole reason behind this initiative was to secure enterprise customers, or remove sales objections that might have blocked deals in the past. 

So, now you are compliant, make sure the Sales and Marketing Team are all over it. Here are some things you could do to drive awareness of your enterprise-readiness…

• Add the compliance badges to your website (the footer is a nice place, have a look below to see ours).
• Reach out to any ‘Closed Lost’ prospects where not having the compliance certification was the deal breaker, and see if you can win them over now.
• Try some Account Based Marketing and target a list of relevant, enterprise organizations that match your Ideal Customer Profile (ICP). Consider contacting their procurement teams (the people who will care about compliance the most) to get on their radar as a possible software solution.

Achieving enterprise readiness through compliance is a meticulous and ongoing process, but it’s worth it to enhance your software’s market appeal and build trust with your enterprise customers.

By following these steps, you can ensure your software meets the rigorous demands of enterprise-level deployment, which will give you a solid foundation for growth and success in the competitive software market.

What’s the newest compliance requirement to be enterprise-ready? 

The EU AI Act! 

As the European Union prepares to implement the AI Act, a pioneering piece of legislation designed to regulate the use of artificial intelligence across its member states, software enterprises and Product Managers should take note!

The act introduces a risk-based classification system for AI applications, setting out requirements and compliance standards from minimal to unacceptable risks. Understanding and adhering to these classifications will be critical, not just to avoid hefty fines, but also to ensure your products meet the EU’s rigorous safety and ethical standards.

The implications of the EU AI Act go further than mere legal compliance, though. If you proactively align your AI deployments with the act’s requirements early on, you could gain a competitive edge, fostering trust and credibility among European consumers and businesses.

This alignment will go a long way to emphasize your company’s commitment to principles that are increasingly valued in the global marketplace, such as ethical AI development, focusing on transparency, accountability, and the safeguarding of fundamental rights. This will help ensure you’re enterprise-ready going forward into the AI age, as large businesses adjust to the growing regulatory frameworks.

For companies aiming to penetrate or expand within the European market, compliance with the EU AI Act will be, to put a fine point on it, non-negotiable. Early adaptation to its requirements will ensure a smoother market entry and operations generally. And you can be sure that other regulations will follow worldwide, which you’ll already be geared up to address.

It just goes to show how important it is to stay informed and responsive to the evolving regulatory landscape, both in AI technologies and in the tech field as a whole. Ensuring a proactive approach not only mitigates risk but will help position your company as a leader in the responsible use and development of AI.

SOC it 2 them

It’s important to remember that achieving enterprise-ready compliance is more than a regulatory hurdle; it’s a commitment to excellence and an opportunity to set your software apart in a crowded marketplace. Plus, if you manage it, pulling in enterprise customers is sure to do wonders for your revenue .

By fostering a culture of compliance, embracing the roles each team member plays, and staying informed about regulations like the EU AI Act, you’re not just getting your software enterprise ready – you’re preparing your company for future success.

So let’s turn this compliance journey into a stepping stone for building better, safer, and more reliable software. Your grandkids will thank you for it when they’re not being riddled with lazers by Terminators.

The post How to Get Enterprise-Ready: Making Your Software Compliant appeared first on ProdPad.

So I’ve been through the mill when it comes to building AI features. I’ve learnt a lot and had a load of fun doing it! I’ve also spent a lot of time talking to other product people, engineers and developers and learning from their experiences with AI. 

All of that has brought me here – to this list of the key considerations when building an AI product. Let’s dive in…

1. Avoid gimmicks

First and foremost, what you are building has to solve an actual problem for your users and customers. Don’t make the mistake of creating an AI product or feature that is just a gimmick. A gimmick might get clicks but that is all it will get. No subscribers, no sales. As with all product management, putting lipstick on a pig isn’t going to help you and will likely only cause problems for you longer term.

Do not run off and start building an AI feature because the boss is shouting ‘why don’t we have AI??’. Make sure you stick to your product management principles and first do proper user research to discover the pain points your customers have, THEN think about how AI could solve them.

AI can and does solve real problems. But, the reality is the types of problems AI is best at solving are often fairly boring problems. It’s rarely sexy stuff. However, those slightly boring, everyday problems are the problems people will pay you to solve for them. It’s making the boring stuff go away that will please people the most. See consideration 6 for more on this. 

Often the driver for the AI gimmick is marketing or funding considerations. However, as people are getting used to and understand more about how AI can help them, these marketing and funding gimmicks will backfire.

2. Understand the ‘magic valley’

Have you come across the concept of the uncanny valley before? It was introduced by robotics professor Masahiro Mori back in 1970. When plotting the human emotional reaction to robots, the uncanny valley is the dip in the graph where the emotional response becomes negative, correlating with the point at which the likeness to humans becomes too great. In short, we get a bit uneasy and a little repulsed (aka freaked out) when things are too human-like. 

And just as humans have this uncanny valley in robotics and human representations, there is a similar valley for the “magic” of AI. Knowing how your users and stakeholders will respond to different amounts of magic is important to the success of your AI powered product and features. You don’t want to weird anyone out! 

The magic valley is created from the combination of level of control (or more accurately the desired level of control) and the quality of the results. As each feature/product is different, you’ll need to experiment with different levels of control and results in order to get the level of magic right.

Too much control can be just as bad as too little. Most people won’t be sufficiently proficient on fine tuning/tweaking to produce good results on their own. Nor should they. Your users should be focused on using AI products and features to be more effective, not twiddling knobs to get good results. 

3. Set expectations properly

It can be tempting with AI products and features to sell the universe. Don’t. Like everything else in the world, AI is not perfect and as news headlines attest to, often gets it wrong. By selling the dream that AI will wash your dishes, clean the house and fold laundry while doing your job, you will disappoint and cause disillusionment with your product.

That isn’t to say you can’t sell the value, but you have to calibrate the sell to the actual value you are delivering and the problem you are solving. 

Let’s consider an example. There are an increasing number of content producing AI products that are basically selling themselves as producing Pulitzer prize level content that can be immediately published. They aren’t. These products might get you 60% or even 70% of the way there but you’ll still need to edit, revamp and otherwise improve. 

There are multiple reasons for needing to improve this content, not the least of which is dealing with hallucinations and lack of knowledge about a topic.  

What these products are doing is getting that rough first draft going. Overcoming the blank page syndrome, which is a real problem and there’s a lot of value in solving this issue.  But that isn’t necessarily sexy sales or marketing.

4. Understand the ethical and legal matters

Depending on what you are trying to do with AI, you’ll have differing levels of ethical and legal considerations. Generating user stories has a different level of ethical considerations than AI that is making a decision such as whether someone gets a mortgage or into a University.

As a product manager you’ll need to stay on top of the evolving statutory and regulatory environment. The legal aspects of the models will take years to play out in the courts in various jurisdictions. 

Be aware that you’ll probably face a very different regulatory environment in EU countries to that of the RoW even to the extent that some AI products and features maywill be unfeasible to provide in EU countries.

You should also consider the security of your customers’ data and the information they will need to feel happy with what you’re doing with it. This comes down to what AI service you are using and how you are working with it. If you’re relying on ChatGPT, for example, it’s worth familiarizing yourself with the case of Samsung. 

Samsung banned the use of ChatGPT and other AI products among its employees when it was discovered that some sensitive internal source code was uploaded to ChatGPT. Samsung feared that their sensitive code would be used to feed the ChatGPT model and could end up being shown to a ChatGPT user in the future.

Now, OpenAI actually changed the way they work back in March 2023 so that nothing going into ChatGPT or via their API endpoints now feds into the general model. But I’d say that isn’t widely known.

Certainly here at ProdPad, we found a number of our customers – especially those Enterprise customers from multinational household brands – asking for reassurances that their important strategic information was not at risk of being stored by OpenAI. Happily we had the info on hand and could reassure our customers that they are safe to use our features without the risk of having their secrets shared with the world through ChatGPT.

Therefore, especially if you’re managing a B2B product, I suggest you be ready with support materials or help center articles that explain how it all works and give customers the reassurances they may be seeking. You don’t want a lack of understanding to restrict the adoption of your AI product or features.  

5. Deterministic vs non-deterministic behavior

AI is non-deterministic, which basically means that for the same input you aren’t likely to get the same output each time you use it. It should be similar but not the same. This contrasts with other technologies which are deterministic. For the same input you get the same output each time it is used.

Being non-deterministic has a massive impact on the UX of using AI products and features. Not only in how you explain the results but also in the actual production of the results. 

A good example of this behaviour is that while you can ask GPT models to produce JSON using a specific schema, it won’t always produce the answer in the schema and you’ll need to be able handle that.

Considering that previously people could press a button and get the same result each time, the UI now also needs to prepare users that this is no longer always true with AI-powered features. Overtime people will become used to non-deterministic behaviour, but for now you’ll need to hand hold them so they can adapt to this change.

6. Biggest bang for your buck is boring

AI products and features that will be successful in the market are the ones that automate away drudgery. For example, the most used AI feature in ProdPad is our user story generator. Why? Because it automates away a lot of the drudgery of product management, taking an idea and functional definition and converting into user stories to pass to the delivery team.

The single biggest win for AI products and features is addressing boring and tedious tasks. Even if it is about just getting started.

7. Get ready to move. Fast

If you’re planning to add AI features to an existing product, chances are you’re hoping this will give you a competitive advantage. That or you’re trying to catch up with competitors who have gotten ahead of the curve and have AI offerings out in the market before you. Either way, speed is important here. 

I’ve already warned against the pitfall of the AI gimmick, so you don’t want to move so fast that you’re forgoing proper discovery and research, but you probably do need to move at a faster pace than you’ve been used to previously. 

That’s because everyone is now racing to take advantage of both the developments in AI technology and the consumer appetite for it. Soon features perceived as game-changing and unique will start to be regarded as a standard requirement. In the Kano Model view, certain AI capabilities will move from being Delighters that really impress potential customers, to Basic must-have requirements. 

Therefore, it’s worth rallying the troops before you embark on your AI quest, and getting everyone prepared for the pace you want to move at. Remember, this is all exciting and fun to work on! The team should be motivated to get stuck into this and spec, build, ship, promote and sell some truly useful features in quick succession.  

Here at ProdPad we managed to get a real whirlwind of enthusiasm going within the team and have been releasing an AI feature or major enhancement every single week. That’s how we’ve managed to have the most robust set of AI tools of any product management platform.   

8. Have Sales & Marketing ready to roll

This relates to the point above – moving fast – but it’s worth pulling out as its own consideration. That’s because it really can be the make or break of your AI success. 

You’ll want to sit down with the marketing team as early as possible. Do not leave it to the final hour to speak to marketing and tell them about something you’ve already built. If you want to do this right, you need to consider the marketing message and value proposition of the AI product or feature before you start speccing and building. 

You’ll want this in place for two reasons. Firstly it’ll mean there’s no delay when it comes time to go-to-market with your AI product, and secondly, it’ll ensure you have full alignment around the value proposition and what ends up getting built fits with the promise you want to make to the world through your messaging.  

Getting marketing heads involved in the early thinking will help you avoid the gimmick trap. This might sound surprising, after all, no one enjoys a click more than a marketer , but as the protectors of the brand message, the marketing team will be really well placed to advise on whether your idea for an AI feature actually sits comfortably with the core value proposition of your overall product. If it doesn’t, there’s a high chance you’re doing AI for AI’s sake rather than using AI to further solve the problems your product vision sets out to solve. 

You’ll also want to loop Sales in sooner rather than later. This is especially important if AI hasn’t been part of your offering up to now. Your Sales team might need extra time to learn some of the basic technical details (so they can answer prospects’ questions) and think about the best way to demo the tools. 

That’s another thing we learnt during our AI experience here at ProdPad – you need to think ahead about the best way to demonstrate the features. Because AI features often rely on a degree of existing data, an empty free trial account isn’t always the best way to show the features off and let people play with them.

In our case, we opened up our sandbox environment and allowed people to play around with our AI tools with a bunch of pre-populated data. This way they can quickly see what the tools could do for them, and then, once they see the value, they can start a free trial and get started with their own data. 

Make sure you take the time early on, to plan how your Sales team can demo the features and show people the value.

If you keep those 8 things in mind as you work through your AI journey, I’m sure you’ll find success! One final thing I would always urge anyone working in the AI space to do, is try as many different AI tools as possible. You can get great ideas from seeing how different products are using AI to solve different problems. With that in mind, I invite you to start a free trial of ProdPad and take our AI tools for a spin. Let me know what you think! 

The post 8 Considerations When Building an AI Product appeared first on ProdPad.

What is AI product management?

AI Product Management is the practice of product management tailored to support the incorporation of the unique behavior of AI technologies into products in order to solve customer problems. It requires greater familiarity with the underlying concepts of various Artificial Intelligence technologies in order to make informed decisions about their application to solve customer problems.

AI product management brings some unique user experience challenges. These challenges lie in the trade-off between AI-driven features working like “magic” and the level of customer control.

“Magic” here refers to how much of the process is automated, and how many things are just done without any user input or control. While it can seem attractive to make everything very “magical”, you have to weigh that up against data protection, privacy, and user expectations.

What is an AI product manager?

The AI product manager is a PM with the appropriate understanding of the concepts of AI technologies, who can use this knowledge along with the practice of product management to apply AI to products in a way that ensures it’s not merely a gimmick, but in fact addresses a genuine customer problem.

What’s the difference between a traditional product manager and an AI product manager?

Unlike regular product managers, an AI product manager has to contend with the basic fact that the majority of AI technologies are non-deterministic. Clicking the AI button won’t always produce the same result, unlike when you use deterministic technologies. A simple example would be a calculator – you get the same answer from the same inputs every time.

The challenge for the AI product manager during the product development process is constraining the AI technology to produce bounded responses to input, and that those bounded responses remain useful and effective to customers.

The other challenge that an AI product manager faces, particularly with Generative AI technologies, is that those can often hallucinate (which is a polite way of saying that they sometimes “make sh*t up”).

AI product managers have to be able to train or constrain the AI to reduce the amount of sh*t it makes up, and to find ways for customers using these technologies to spot and feed back when the AI is making sh*t up.

This isn’t to say that the AI product managers will be developing the model or AI technologies themselves. However, they should be comfortable with being able to test and prototype prompts and other AI inputs with or without specialists, to be able to characterize how they will be used in a product.

The growth of AI product management

A quick scroll through Product Hunt’s list of the best AI apps and products of 2023 reveals that there are already hundreds of 5-star-rated products on the market right now that incorporate, or entirely focus on, providing AI-powered answers to users’ needs.

There are over 800 listings in the US alone when you search for ‘AI product manager’ on Indeed.com, another 100 in the UK, and that’s not even looking at burgeoning Tech centers like China and India.

Staying ahead of the curve is vital in product design when game-changing tech like the recent wave of AI comes along. That’s why I’ve put together this primer to help you catch up, so you can then get ahead.

Why is AI and ML so important for software product managers?

At the core, AI and Machine Learning (ML) are productivity enhancers. They enable a user to do things faster, or even to do things that they couldn’t effectively do before.

Some AI technologies allow products to process large amounts of data (log files, for example) to spot anomalies, and others are able to compare protein shapes at scale. These AI tools simplify tasks that are prohibitively expensive or impractical for humans to do.

Other AI technologies apply directly to individuals’ day-to-day work and allow them to be more productive by focusing on higher-value activities. On a side note, these are the applications that many feel will destroy jobs in a similar vein to the Industrial Revolution.

Just as product managers will apply AI to their products, they should be looking at how AI can help them with the practice of product management. The biggest win is overcoming the blank page syndrome and getting a starting point going – like generating a first draft of user stories for an idea, or filling out the idea canvas for a new idea.

Making the AI work for you

The right product with the right AI toolkit (like ProdPad, for example) will help manage the deluge of feedback, summarizing and grouping it into useful insights.

While we’re still at the relatively early stages of the AI Revolution, the productivity increases and quality-of-life upgrades these tools can provide will soon move from being delighters to being a basic expectation. Not just for your users, but also for you as an AI product manager as part of your daily workflow.

If you’re familiar with the Kano model, you’ll know how you can categorize features based on customer perception and satisfaction, with those categories going from Dissatisfied and Indifferent and Basic, to Performance and Delighter.

It’s standard for new functionality, services, and features to start life as Delighters, and then to gradually move down through the categories until they become a Basic requirement – a minimum expectation for customers.

Have a look at our Glossary page on the Kano model for another example to help illustrate this. But in the case of AI, we can expect the trajectory of AI features to travel that same path.

That’s why is so important to get your head around these changes now and to start making use of them yourself as soon as possible. You don’t want to be playing catch-up with your competitors, you need to be at the bleeding edge. You can be damn sure everyone else worth talking about is trying to be.

Moving into AI product management

As a still new and evolving sub-discipline of product management, moving into AI product management doesn’t have many hurdles. The largest is being able to understand the concepts behind the various AI technologies.

With that in mind, here are my suggestions for how to find the knowledge you need to make your move into an AI specialism.

As the majority of AI technology that is generally applicable will be Generative AI, being able to prototype and define prompts for the developers to implement is a strong must. Luckily, OpenAI has an interactive playground and good documentation on writing prompts. It’s a great way of getting started with learning how to write prompts, even if you don’t end up using OpenAI’s generative AI models in your product.

Other good learning resources are Hugging Face, FastML, and Microsoft Azure AI services. In addition, there are many (free as well as paid) courses on AI/Machine Learning such as those offered by Udemy, Coursera, and MIT.

In terms of people to follow, a few to get you started are Andrew Ng, Fei-Fei Li, and Yann LeCun. There are so many people talking, researching, and writing well about AI/ML at the moment, so use the ones above as a leaping-off point to find more expert insights.

And finally, head here for a really helpful list of even more AI/ML resources.

Interview tips for an AI product manager role

With the proliferation of AI products, you’re likely to see more and more AI product manager roles being advertised – heck, it might even become the most common product role in the market! Another reason why you’d be smart to start specializing.

There’s a lot you’ll need to get your head around if you’re going to be able to convince your interviewers that you know what you’re talking about.

So here are my top tips for impressing at any AI product manager job interview:

• Understand the underlying concepts of AI, including:
  • Neural networks
  • Large Language Models
  • Deep learning
  • Natural Language Processing
• Know the difference between embeddings, prompts, and LLMs (particularly if going for a Generative AI role).
• Have a few examples of problems AI can solve, which are the best AI techniques to solve the problem, and why.
• Understand and be able to speak to the ethical considerations in the use of AI technologies – e.g. how bias in the data set can bias a model, and result in human harm.
• Be aware of the emerging legal implications of using AI.

With all of this in mind, and by staying on top of the ongoing developments in the field, you’ll be sure to impress in your next interview, and you’ll have the knowledge necessary to guide the successful development of your products through the AI revolution.

The post Being an AI Product Manager: Everything You Need to Know appeared first on ProdPad.

• What a technology roadmap is
• Why you should create a technology roadmap
• The benefits of a technology roadmap
• The technology roadmap process
• A useful template and example to work from

What is a technology roadmap?

A technology roadmap is a visual tool that describes a company’s technology strategy. You might call it an IT roadmap, a software engineering roadmap, an architecture roadmap, or similar. Whatever its name, it describes the technical infrastructure, why you’re working on it, and what the benefits of this work will be.

Why create a technology roadmap?

Any technology change needs a roadmap because of the profound impact it might have on a business. A change in one area might open up problems or a need for change somewhere else.

For example, the business is self-hosting some tools and wants to stop maintaining servers and move them to the cloud. During the move, there needs to be minimal disruption to the tools, users, and data they access and produce. That requires careful planning. A technology roadmap, as a visual representation of this strategy, helps IT staff, to fully consider the implications and impact.

the content of a technology roadmap to some extent depends on the type of organization creating it. A supermarket’s technology roadmap, for example, will be different from ProdPad’s technology roadmap. 

Let’s think about why this is. At ProdPad, the technology is effectively the business – it’s embedded in our product and can’t be separated from the product. Our technology roadmap is hugely influenced by our product strategy and how we expect the product to develop. 

By contrast, a grocery store sells groceries and other consumer goods. It likely has a fair number of technology roadmaps designed to manage innovation in different parts of the business. There will be technology roadmaps for its checkout systems, ERP systems, CRM systems, and so on. 

For a company where technology helps them deliver their services like a grocery store chain – it is imperative to have a strategic technology roadmap in place. Because of the many spinning parts that could be affected in different areas of the business that might not talk to each other.  

What are the benefits of a technology roadmap?

The benefit of a technology roadmap is that it makes you think strategically about what you’re doing.

It shows stakeholders the current tech solutions and how they align with company and product goals. Technology moves fast and can be a significant cost to the business. A technology roadmap helps you to move in the right direction and invest sensibly. This boosts transparency across the business enabling other departments to see where the money is being spent.

It makes you consider whether planned initiatives will help the business’ technology strategy. It may even be that you decide that a planned initiative doesn’t deliver on the technology strategy. Leading you to re-evaluate whether the current strategy is in fact driving toward the business and product goals. 

Process and planning are pivotal

In a previous life, I spent some time in the Australian Army. During my training, I was taught that planning was vital, but that the content of the plan was less important. This is because the plan itself can always change. The planning process – what you need to do, achieve, and what to do if things go wrong – is what’s crucial.

This same ethos applies to a roadmap, whatever sort of roadmap it is. The roadmap planning process means that when things do go wrong, you already know how to fix them.

A technology roadmap keeps the team on track during implementation and keeps scope creep in check. We all know of technology and infrastructure projects that went wrong. Their scope expanded exponentially, went way over time or budget, was canceled, or never delivered on their initial objectives. 

Communication is key

Shared with the business, customers, stakeholders, and investors, your roadmap is a powerful marketing tool to communicate the business vision. We’ve all seen huge interest generated whenever a big tech business like Apple or Google talks about its product roadmaps. 

Transparency pays – research shows that customers are likely to be more loyal and pay more for guaranteed total transparency. (How Transparency In Business Leads to Customer Growth and Loyalty).

Microsoft even makes a point of publishing technology roadmaps for all its products. Here, for example, is the current Microsoft 365 roadmap. This gives customers and third-party developers the opportunity to plan projects, schedule migrations, and plan purchases with confidence. 

What is a technology roadmap process?

In my experience, most businesses use a timeline-based Gantt chart to show their technology roadmap. Then they try to work out if it fits with their product strategy. This is a project management-type release plan, not a roadmap. This is a mistake – you start too close to the end and don’t give yourself room to deliver your strategy.

Far better to start by asking what technology does for the business. Starting here you’ll be clear about whether the technology strategy supports the business and product strategy effectively.

Like a product roadmap, you break a technology roadmap up into smaller initiatives that are understandable and manageable. A big infrastructure project, that takes two or three years, is only manageable if broken down into smaller chunks. 

Its intended audience is important. Senior stakeholders will probably want only a high-level overview. They don’t need the same level of detail as a tech team, but they will want to know the project’s benefits. 

Now we’ve talked about the what and the why when it comes to a technology roadmap let’s focus on the how. I’ve created a simple and easy framework to follow to ensure you develop a technology roadmap that keeps strategy at the front and center. 

Let’s dive in.

How to create a technology roadmap

This list is completely straightforward and easy to follow. However, as we’re over-achievers when it comes to adding value, so we’ve also created an example technology roadmap in our sandbox and we’ll use it as an example below.

1. Pinpoint strategic objectives

Start with the what and the why. What are the strategic objectives? Why do we need to make these changes? For our example roadmap I’ve selected three common objectives a technology roadmap needs to have:

1. Secure the company systems
2. Improve IT processes
3. Support compliance requirements

How did I get these three objectives? I started with an end goal, which was keeping the company up-to-date and secure with a streamlined process.

Clearly articulate how the technology needs to be changed. This should be easy for everyone to understand and to see how it supports the business and product strategy.

Now that you’ve got your objectives you can break the work down further into manageable initiatives. 

2. Set out the new system’s capabilities 

This is where the goal of the task is fully articulated. Set out the capabilities that will now be accessible to you and your team by adding new functionality, systems, or tools.

Setting out the full capabilities means that you fully explore the benefits and pitfalls. It will give you a 360 view of what you are bringing in and what else might need to be added to your roadmap.

3. Determine needs and priorities

This is pretty obvious, right? Some things need to be done right away, some things need to be done before something else can be done and some things can be done at some point. And it’s your job to work out the order of those things.

So really look at what problems you are trying to solve, and set initiatives that will get you moving towards your objectives.

Let’s again look at our roadmap example and the initiatives that are attached to the objective to secure the company systems. It’s a pretty straightforward objective but there are loads of ways to achieve this, but without initiatives and processes in place, you could end up with a scatter-gun plan that leaves you with even more processes to unpick.

So we’ve set an initiative in the Now column called “Implement SSO in SaaS tools”. From there your team can identify all the SaaS tools in use within the company, ensure that they set the process for all of those tools, and ensure there is complete adoption of SSO across the board. 

You’ll also see that in the Next column we’ve also added  “Implement SSO in internal tools”, the logical next step after a successful roll-out of SSO within all the SaaS tools. 

This ensures that your team continually identifies new areas that need to be optimized with a methodical and strategic approach to analysis.

4. Measure the cost

You don’t just need to think about the cost of buying a license or software fees, there’s also the cost of people’s time and the cost of not doing it. This includes risk factors and other complicating factors.

Sometimes it’s more expensive in the long run not to do something.

5. Decide on timelines

Once you’ve got everything in place it’s time to map out the release plan, when you’ll be giving status updates, and how long certain things are going to take. A lot of the time deadlines will be arbitrary and possibly unneeded. You and your team know how much you can do in a sprint, having a deadline on an entire initiative can be counterproductive and lead to long conversations with stakeholders if you go over time.

6. Assign responsibilities 

Lots of people are involved in the successful delivery of your plan, so you need to ensure they’re all adequately prepared and understand their roles and responsibilities within the delivery of the work.

7. Keep revisiting these points. 

Most importantly, don’t forget to allow your technology roadmap to evolve. Technology moves fast. Today’s groundbreaking piece of kit can quickly become yesterday’s thing, so accept that some of your assumptions might be invalid by the time you get to them. Those up-to-date routers you planned to put in for that company-wide zero-trust initiative may well have been superseded by something else by the time you come to install them.  

An Example of a Technology Roadmap

We’ve created a working example of a technology roadmap within our sandbox, it’s live and ready for you to explore. You can explore adding objectives, ideas, and feedback and see how your technology roadmap could work. 

Once you feel like you’ve got the idea, why not start a trial and start to share your technology roadmap with your stakeholders? Now-Next-Later is such a simple template to follow but it’s the most powerful way to ensure your technology strategy is delivered effectively.

And finally

A technology roadmap can be a really valuable tool to plan, visualize and manage a technology change. It gives stakeholders a clear view of the benefits of any change and gives the teams involved a clear view of their objectives and resources. It should always help you to think strategically about the changes being made and whether they benefit the business’ strategic and product goals.

The post How to Create a Technology Roadmap appeared first on ProdPad.

Product roadmaps vs release plans: the difference

When comparing product roadmaps vs release plans, you need to understand that the roadmap and the release plan are two different tools, one used after the other. The first is exploratory and informative (strategy), the second is practical and applicable (execution).

A product roadmap shows what is coming up (Now, Next and Later) and what is being worked on at this moment. This allows teams other than product and engineering to see what’s coming down the pipeline and plan their own work as needed.

The release plan is about coordinating the launch of what’s already been built, particularly with the efforts of other teams in relation to the launch. This includes marketing campaigns, sales campaigns, closing the customer loop, measuring the success of the release, etc. All of these activities are put on a timeline.

The roadmap gives the whole company visibility of what is coming up without causing problems by tying things to a date. The release plan takes over when development is done and coordinates the wider team’s activities to make all major releases a success.

The confusion between product roadmaps vs release plans

This transition from roadmap to release plan is where the worlds of product management and product development can get a little murky. In many organizations, they’ve started to merge or overlap. Indeed, this is how so-called “timeline roadmaps” have come to be a common practice.

Maybe some teams think they’re being efficient by doing both in one go, in one discussion, in one tool. But actually, you’re doing a disservice to yourself, your company, and your customers.

Great product management isn’t possible when it’s tied to timelines. And great release planning is about so much more than the product launch itself. By separating these two processes, you’ll build a better product and deliver that product more successfully. 

The downsides of a timeline roadmap

If you’re using a timeline roadmap you are basically using a glorified release plan to manage your product strategy. You’re mixing up in the differences between product roadmaps vs release plans and combining two distinct processes that are each critical to your company’s success.

Here are three reasons why this mix-up is a problem.

Timeline roadmaps are more about development than they are about product discovery, strategy, or your product vision. The team’s focus moves from the problems you’re trying to solve — to the features you’ve plucked from the backlog and decided to build.

Taking a step back to look at the problems facing your business and users as well as your common goals is what keeps your roadmap fresh and adaptive to change. These changes could be in the market (you have a new competitor) or new insights about how your customers use your product.

But when you’re running a feature-focused timeline roadmap, you’re less agile across the board.

With timeline roadmaps, some teams plan for a whole year in advance (or even longer), which doesn’t make sense! Why would you tie your own hands? When you make promises to senior stakeholders and customers, you lose the ability to change direction and pivot your strategic goals. People expect you to hit X target by Z date. Perhaps you can change direction after what you’ve committed, but not before. And then it might be too late.

Bottom line: long-term product commitments can mean building the wrong things and missing the right opportunities.

When timeline commitments absolutely must be changed, this can be a huge burden for PMs on a psychological level. Stakeholders don’t want the dates changed. So then it’s your job to get them to agree to the changes and accept that these changes are worthwhile, maintaining their trust in the process.

This requires too much time and effort on your part. And if it happens repeatedly, resentment can build up between teams.

The benefits of a horizon roadmap and separate release planning

There’s a better way than using a timeline. Horizon roadmap is about the problem you’re solving. At Prodpad we advocate for horizon or lean roadmaps. Here’s why:

When you’re focused on problems that need solving, you allow for continuous discovery and experimentation. Your vision for potential solutions is much wider, so you generate more of them, and they’re more creative than if you’d stayed in the box of your backlog or timeline.

Ultimately you find the best fit for your product and your company objectives. 

The release plan is shorter, perhaps covering just the next two cycles of upcoming releases rather than the next 12 months. With this closer focus comes a smaller level of granularity — you understand the details of what needs to be done, how long it will take, and when it will be ready.

With the lean roadmap, it’s much clearer what is currently being worked on and when it will be delivered thanks to it’s visual representation.

You can finally make realistic promises to the rest of the company! With a transparent and reliable product pipeline, other teams will feel more confident in their own work, campaigns, and aligned efforts. This of course ripples out to executives, customers, and other stakeholders. Less friction, higher morale.

How to separate your product roadmap and release planning

If you’re ready to stop the fight between product roadmaps vs release plans, and instead want them to work in harmony you need to first separate your product strategy from your development timeline, here are a few steps on how to do it.

1. Recenter the problems you’re solving in each cycle. Make them explicit! And tie each delivery or feature idea back to a problem or one of many user stories. For more on this, check out Janna’s thoughts on product prioritization models and how to prioritize on a “Problem Level.”
2. Shorten your timeline. Look at the current development cycle and the next one only. Don’t look six months down the road, and don’t make commitments into the future! If you’re pressured to provide time estimates, pull back on precision (no exact dates) and emphasize the new problem-focused approach.
3. Separate discussions and hold separate meetings. This could help the team adjust to thinking about roadmap strategy and release planning separately. There would be one meeting for product strategy and prioritization discussions, and another for committing development resources and timeline planning. To define a release planning process for your team, check out how to master release planning.

The post Product Roadmaps vs Release Plans: Understanding the Difference appeared first on ProdPad.

What is feature prioritization?

Fundamentally, feature prioritization is about picking what to do next. Not only what to build next, but also what to user-test, nurture, research and so on. It’s about making a decision.

As a product manager, you have overwhelming lists of things to do, build, research, nurture, test, but you can only ever work on a small subset of those great lists. Prioritization helps to pull out the subset of what you can achieve within your constraints that will bring the most benefit to your organization, product or service. Put another way, feature prioritization is how you query your problem sets in order to pull out what you need to focus on.

Good prioritization principles

There are lots of systems and methods for prioritizing. Whatever system or method you choose, the following principles make for a good implementation of prioritization, so do keep them in mind:

Ultimately, if you can’t explain it and your team either doesn’t use it or games it for their own end then you don’t have a functional prioritization system. As a result you are more than likely doing the wrong things, from picking features that add no value to building low-impact features before high-impact features.

Beware of complexity

Complexity is the single biggest enemy of effective prioritization. This is because complex prioritization systems inevitably require lots of tweaks and adjustments which get in the way of adjusting to changing market and economic conditions. The more complex your prioritization system, the more time you spend managing it and less time you spend doing the work.

Complex algorithm-based approaches to feature prioritization can end up being too hard to explain and becoming something of a “black box”. As soon as the black box starts throwing up what are judged to be nonsensical results, people lose trust and the results are fudged to ensure the results match expectations. At this point it’s likely easier to ditch the black box and go back to common sense.

What’s important

Feature prioritization is key to focusing on what delivers the greatest benefit to your organization, product or service, given the constraints you face. A good prioritization system should be simple, explainable and judgement based, relying on judgement of the relevant stakeholders (for example developers on effort and product managers on the impact).

You’ll know your prioritization method is working when the stakeholders understand how it works and are engaged with it. If done with understanding of your customers, then you’ll see greater engagement and adoption as you address customer needs and problems.

If you rely on complex algorithmic approaches to prioritize your backlog and your computer saying “Yes”, you are in for a world of hurt.

The post Feature prioritization principles in Product Management appeared first on ProdPad.

Before I started to use a lean roadmap format, I found that every month, like clockwork, I would push forward items on the roadmap and rearrange the order. Here was a roadmap that should be showing what order and when we would deliver things – except it changed constantly. 

The reason my roadmaps changed so much was that we would release something, gather feedback and then realize that our assumptions were wrong. Those same assumptions underpinned our prioritization and consequently the Gantt roadmap. The constant change made a nonsense of our timeline roadmap.

As my experience shows, if product roadmaps are to work and be useful to organisations they need to embrace uncertainty and assume change. 

The trouble with timeline roadmaps

Timeline roadmaps, or Gantt charts, assume that you know what you need to do first, second, and so on, from a list of features that you want to build. But in reality, product managers usually have a backlog of features and no real sense of the order to build them.

What’s more, the prioritization algorithms and frameworks that allow product managers to give order to their backlog – RICE, Weighted Scoring and the like – all share the fundamental assumption that there is an absolute order of delivery (or importance) between the different features. 

The assumption is necessary to ensure that timeline/Gantt roadmaps are usable. They need an order of features to build that doesn’t change with time. Timeline roadmaps only work with the assumption that priorities are absolute and don’t change over time.

But priorities change. They change with markets, as products evolve, and as users evolve. The dynamics of user needs, desires and market forces mean that there cannot be an unchanging order for building features.

A timeline roadmap/Gantt chart isn’t really a roadmap, just a list of features that need to be built.

Embrace uncertainty with a lean roadmap

A lean roadmap embraces uncertainty and assumes that things will change. It’s not about features, rather problems that you can solve. 

With a lean roadmap you still have to choose the order of which problems to tackle and when. You can use frameworks like RICE or Weighted Scoring with a lean roadmap, but neither are ideal. This is because both assume an absolute order, whereas you are prioritizing relative to the other, strategic, problems.

It’s better to prioritize by looking at how the problems support the product and company strategy through achieving the objectives. Then you can look at how that works with the market and product feedback about the problems. Have a look at this post, Putting it all Together – Creating a Lean Objective-Based Product Roadmap for more detail.

Summary

The style of roadmap you use determines your approach to prioritization, but you should beware the fundamental flaw of assuming that an unvarying, absolute order exists with a timeline roadmap. In reality most product managers inherently recognize this in all the tweaking and eventual manual re-ordering of priorities that they do. Ultimately, you can’t really fix that fundamental flaw by tweaking. Lean roadmap and native prioritization approaches are better suited to the reality of product management.

Read more: Feature prioritization principles in Product Management

The post Fix your prioritization problems with a lean roadmap appeared first on ProdPad.

In reality though a release isn’t over at that point but is only beginning. Once the code hits the server, marketing can begin planning and conducting their campaigns, customer success can contact interested parties and sales can plan and conduct their campaigns. All that can and should happen *after* the code hits the servers not in the lead up.

Why?

Even with the best QA processes in place, it is better to let changes “live” in the wild for a bit before you go and shout about them. Bugs will be found, stuff that is missed will be identified and leaving time to allow the changes to bed in makes sense. You don’t want to conduct a marketing campaign driving leads to buggy features.

What this means is that sales, marketing and customer success don’t necessarily need to know what or when changes are pushed to production. Their work begins once the changes are on the servers. This gives those teams much greater flexibility to manage their parts of releasing to have the most impact for the business.

What about training? What about documentation?

It is quite right that these are arranged before the code hits the servers. But let’s turn that around. Is training and documentation really related to a software release? No, training and documentation should be considered as part of the development process and a change is not ready for release until the documentation and any training are ready and done.

Using this approach releasing works this way:

And what about product? Well that team will start tracking what impact the changes have on the product.

So a software release isn’t about knowing upfront what will go out when but knowing what did go out and when so the other teams are able to coordinate their work.

Releasing isn’t about throwing code over the wall but coordinating ongoing work across multiple teams.

Releasing isn’t about dates but impact.

The post What Is a Software Release? appeared first on ProdPad.