In one of my previous blogs I wrote about building a security startup. Here I would like to elaborate on the product management aspect of a venture.
There are many businesses springing up in the cybersecurity space at the moment. A lot of them are developed by great technologists yet still struggle. The market conditions might be right and the product itself can be secure but it often fails to get traction.
When I’m asked why this might be and what to do about it, my immediate response is to dive deeper and understand the product management function.
In truth, it’s not enough to have a technically flawless solution, it has to align with what your customers want. Moreover, the bar in new product adoption is high. As Nir Eyal famously pointed out in his book Hooked, “for new entrants to stand a chance, they can’t just be better, they must be nine times better … because old habits die hard and new products or services need to offer dramatic improvements to shake users out of old routines. Products that require a high degree of behaviour change are doomed to fail even if the benefits of using the new product are clear and substantial.”
Thankfully, it’s not all doom and gloom – there are things you can do to overcome this challenge.
Depending on the stage of your venture, the most important question to answer is: are people using your product? If not, get to the point where customers are using your product as fast as you can. Then talk to them and learn from them. Find out what problem they are trying to solve.
Provide that solution and measure what matters (revenue, returning usage, renewal rate) and build measurement targets and mechanisms into your specifications.
Disciplined product management is there to bridge the gap between business (sales and marketing) and technology teams. As a product manager, you should support these teams with market analysis, planning, prioritisation, design and measurement based on customer feedback.
Knowledge of the customer and their needs will help define your strategic position and overarching guiding principles to support decision-making in the company.
That strategy in turn should be supported by tactical steps to achieve the vision. We are now beginning to shape actual work deliverables and help the technology teams prioritise them in your development sprints.
Principles described here are applicable in any type of organisation, it doesn’t have to be security specific. The industry you are in matters less than the company culture.
People often focus on tools when talking about product management or adopting agile development. The reality is that it’s often about the culture of collaboration. Break the silos, make sure customer feedback is guiding the development and don’t lose sight of the strategy. Your customers will love it, I promise.
After six years with KPMG’s Cyber Security practice I decided it was time to take on a new challenge. It was a great pleasure helping clients from various industry sectors solve their security issues and I certainly learned a lot and met many fantastic people.
BCG Digital Ventures, an incubation firm that’s part of Boston Consulting Group, has partnered with VFS Global, a world leader in visas and identity management, to found a new London-based venture that is creating a frictionless travel experience.
I joined this tech startup as the Head of Information Security and couldn’t pass on this opportunity to be one of the early members of the leadership team.
I’ll be driving the security and compliance agenda, adjusting to the needs of the dynamic and growing business. I can’t wait to put the skills I learned in consulting into practice and contribute to this company.
I’ll have an opportunity to help create a trusted, seamless, user centred visa application process for consumers and businesses alike, through automation and a cutting edge technology. And that’s exciting!
I’ve recently been involved in a number of digital transformation projects and wanted to share some lessons learned in this blog.
Firstly, there’s no one-size-fits-all approach to successful digital transformation, so it always helps to start with a why. For instance, why is the company considering digitalisation? Perhaps the competitive landscape has changed or some of the existing business models are becoming less relevant in light of new technological trends.
Regardless of the reasons, I would argue that no special digital strategy needs to be developed. Rather, we need to to see how digitalisation supports the overall business strategy, and how digital trends affect your company.
While strategising in the boardroom helps, keeping customers in mind is paramount. Rather than simply digitising existing business processes (such as going paperless), it’s useful to think about them as multiple customer journeys to maximise the value for the consumer.
Design thinking is a good method to use when approaching this, as it helps to create a customer-centric solution. It begins with a deep understanding of customer problems and iterates through prototyping, testing and continuous feedback. This process also aligns well with modern iterative frameworks for software development and broader agile working.
Learning from feedback on your minimal viable product (MVP) helps to refine your initial assumptions and adjust the approach where necessary.
For example, adopting and combining technology like Cloud, Big Data and Machine Learning can help improve the decision-making process in one department, so it can then be adopted by the rest of the enterprise once the business benefits have been validated.
Having a clear data architecture is key in such transformation. It’s rarely about just building a mobile app, but about making better business decisions through effective use of data. Therefore, before embarking on any data analytics initiative, it’s imperative to be clear on why the data is being collected and what it’s going to be used for.
While working with a Power and Utilities company, I helped them securely combine Internet of Things devices and Cloud infrastructure to connect assets to the grid, analyse consumption data to predict and respond to demand and automate inventory management. As outlined above, it started with a relatively small pilot and quickly scaled up across the enterprise.
Yes, traditional companies might not be as nimble as startups, but they have other advantages: assets and data are two obvious ones. Digitalisation can help make this data actionable to better service the customers. To enable this, such companies should seek out not only opportunities to digitise their core functions, but also find new growth areas. If some of the capabilities are missing, they can be acquired by interacting with other members of the ecosystems though partnerships or acquisitions.
It’s not all about technology, however. People play a key role in digital transformation. And I’m not only talking about the customers. Employees in your organisation might have to adopt new ways of working and develop new skills to keep up with the pace of change. Recruitment requirements and models might have to adjust accordingly too.
If you would like to learn more, there’s a free online course on digital transformation developed by BCG in collaboration with the University of Virginia that provides a good summary of current technology trends impacting businesses. Feel free to jump straight to week 4 for the last few modules discussing their framework and some case studies if you are after more practical advice.
Image by John Pastor.
I have worked in the Operational Technology (OT) environment for years, predominantly in major Oil and Gas companies. And yes, we all know that this space can move quite slowly! Companies traditionally employ a waterfall model while managing projects with rigid stage gates, extensive planning and design phases followed by lengthy implementation or development.
It’s historically been difficult to adopt more agile approaches in such an environment for various reasons. For example, I’ve developed architecture blueprints with a view to refresh industrial control assets for a gas and electricity distribution network provider in the UK on a timeline of 7 years. It felt very much like a construction project to me. Which is quite different from the software development culture that typically is all about experimenting and failing fast. I’m not sure about you, but I would not like our power grid to fail fast in the name of agility. The difference in culture is justified: we need to prioritise safety and rigour when it comes to industrial control systems, as the impact of a potential mistake can cost more than a few days’ worth of development effort – it can be human life.
The stakes are not as high when we talk about software development. I’ve spent the past several months in one of the biggest dot-coms in Europe and it was interesting to compare and contrast their agile approach to the more traditional OT space I’ve spent most of my career in. These two worlds can’t be more different.
I arrived to a surprising conclusion though: they are both slow when it comes to security. But for different reasons.
Agile, and Scrum in particular, is great on paper but it’s quite challenging when it comes to security.
Agile works well when small teams are focused on developing products but I found it quite hard to introduce security culture in such an environment. Security often is just not a priority for them.
Teams mostly focus on what they perceive as a business priority. It is a standard practice there to define OKRs – Objectives and Key Results. The teams are then measured on how well they achieved those. So say if they’ve met 70% of their OKRs, they had a good quarter. Guess what – security always ends up in the other bottom 30% and security-related backlog items get de-prioritised.
DevOps works well for product improvement, but it can be quite bad for security. For instance, when a new API or a new security process is introduced, it has to touch a lot of teams which can be a stakeholder management nightmare in such an environment. A security product has to be shoe horned across multiple DevOps teams, where every team has its own set of OKRs, resulting in natural resistance to collaborate.
In a way, both OT and DevOps move slowly when it comes to security. But what do you do about it?
The answer might lie in setting the tone from the top and making sure that everyone is responsible for security, which I’ve discussed in a series of articles on security culture on this blog and in my book The Psychology of Information Security.
How about running your security team like a DevOps team? When it comes to Agile, minimising the friction for developers is the name of the game: incorporate your security checks in the deployment process, do some automated vulnerability scans, implement continuous control monitoring, describe your security controls in the way developers understand (e.g. user stories) and so on.
Most importantly, gather and analyse data to improve. Where is security failing? Where is it clashing with the business process? What does the business actually need here? Is security helping or impeding? Answering these questions is the first step to understanding where security can add value to the business regardless of the environment: Agile or OT.
Image by Kurt Kurasaki.
Agile frameworks are gaining momentum in software development and beyond. One of them, called Scrum, caught my attention recently.
I’ve had a privilege to work in one of the biggest dot-coms in Europe and immerse myself in the agile environment. I’ve had an opportunity to witness first hand that efficiencies gained through adopting an agile method cannot be underestimated.
To structure my knowledge and practical experience, I’ve decided to study for the Certified Scrum Master (CSM) exam offered by the Scrum Alliance.
I can highly recommend the two-day course which is a pre-requisite for the certification. This short module helps put everything into perspective and allows you to practice some of the key concepts in a safe environment during a number of workshops. For example, I’ve had an opportunity to work with the product backlog, facilitate sprint planning and retrospective sessions and write user stories.
It also clarifies the role of the Scrum Master in the team as a servant-leader and his/her relationship with Product Owner and the development team.
Find out more on the Scrum Alliance website.