In Systems engineering and Requirements engineering, a Non-Functional Requirement (NFR) is a requirement that specifies criteria that can be used to judge the operation of a system, rather than specific behaviours. Previously this would be mainly Architecture of the system. For example: Scalability, Accessibility, Capacity. These are all still important, however, it should be about more than this in a SaaS world!

Why do I think this is far more important then ever to get right? From an Architecture perspective, you need to get this right or you will have heavy costs fixing issues in the future. But more importantly you should be setting out to the business what are your expectations of the overall customer experience. You have to remember that software is not a solution on its own, everything from the purchasing journey to the training journey and how you are going to support your customers, are also part of the overall solution, and getting this right will retain customer loyalty.

When thinking of your NFR, think about the experience you want your customers to have and draw out all these journeys, so that every area of the business is aware of their responsibility.  Some questions to ask are:

• Are we going to offer free trials? If so, how are we going to support them? What do we need from development, sales, pre-sales, marketing?
• What is the work flow for customers to purchase? Do we have Account Managers selling? Are we expecting customers to purchase from a portal? Who across the business needs to be involved?
• Are we going to do all training online? Will this be self service? Do we have partners who need to train the software? Are we going to sell the environments?  Who across the business needs to be involved?
• How are we going to support our customers, once they are trained and on-board?

There are many more questions, but all of them will have a potential impact on the overall solution (incl. Architecture) and customer satisfaction. Once you have been through this exercise, most NFRs will be the same for subsequent solutions. But always review the NFRs and learn how you can make the solution better.

According to McKinsey, if a software company grows at only 20%, it has a 92% chance of ceasing to exist within a few years.

This means that software companies – particularly SaaS companies – must look at every advantage possible to stay alive in an ever-competitive market.

Remember it is the small margins that can be the deciding factor as to how successful you are.

Customer analytics can be just one way that gives you that competitive edge.

Whether it is measuring retention, product usage, or on-boarding, SaaS businesses must have comprehensive data collection and usage analytics. This enables them to make agile decisions as to the priorities and direction of their overall solution.

When starting a project, make sure that usage analytics are part of the initial NFRs (Non-Functional Requirements).  Think about: what information do you want to understand and act upon.

Ask your stakeholders what information would they find useful to support their business area so they can offer the best service they possibly can.

Ensure the Architect and development lead build in these analytics from the beginning – you want the feedback at every opportunity.

I am interested in what Product Leaders think makes a good Product Manager? And what is your way of identifying a good Product Manager?

I am constantly asked what makes a great Product Manager and what do I look for. I am a great believer that a strong Product Manager is the CEO of their solution. They need to get involved in all aspects, from inception to launch, and then in-life management.  It’s for this reason that I am a strong believer in ‘You hire for attitude, train for skill’. If someone has the right behaviours then you can teach them the skills to be a great product manager. I have learnt over many years that a title doesn’t make the person good at their role.

My approach to interviewing is that the first interview is to understand the candidate’s personality. So I tend to ask myself:

• Can they fit into the team dynamic? (If you want to disrupt the ‘status quo’ to strengthen then that is OK too)
• What does their personality bring to the team that is currently missing?
• Do I think they can work within a team, yet be focused enough to work on their own and drive the solutions that they will be managing?
• Are they tenacious and can they prove this?
• Have they got the right social skills to be able to work with a number of disciplines around the company? They will need to be able to communicate and influence different types of people.
• Are they someone that thrives on ownership and responsibility?

Using this approach means they get to know mine and the company’s expectations. And at the same time, this 1-2-1 personal approach to the first interview allows the candidate to understand if the company is the right fit for them.

Question:            When do you start to launch your solution?

Answer:                 As soon as you can.

Remember you are delivering a solution not just software.  A lot of companies make the mistake that they are purely building software and as soon as the software is ready, then they can release.

But the solution is greater than just the software, it is making sure your business and wrap around services are ready as well. This includes:

• Training materials
• Consultants prepared
• Ordering process tried and tested
• Marketing campaigns understood and ready to action. Advocates ready to help with communication, organise your PR
• Sales enablement complete and sales teams trained
• Support Desk trained and the SLA’s (Service Level agreements) and OLA’s (Operational Level Agreements) are in place
• Software ready. Are you going to trial/pilot?
• Solution feedback mechanisms are in place
• All teams are trained and ready to answer customer queries and evangelise about the solution, using the right value proposition

As soon as you have had the approval for the project to go ahead, and you have secured the budget for development, next step is bringing together your stakeholder group from around the company.  They will help you launch internally and to their peers.

Build a checklist of all the activities and add owners from the stakeholder group.  Have the stakeholders keep you updated with the current progress of their actions, you are not to deliver on their behalf!! The success of the solution will depend on the support of the business, so make sure you have it!

As EdTech companies grow and the nature of technology evolves into the world of SaaS and apps, there’s often confusion around where Product Management should sit in the organisation.

Traditional consumer organisations have had a tendency to consider Product Management in the same arena as Marketing.  However, the danger here is when Marketing is actually ‘Marketing Communications’ (sadly often the case in EdTech) – it means that no-one is involved in defining and delivering the products.

In a lot of Tech companies, the Product Management function tends to be viewed in the technical arena, lumped in with the Development Directorate.  The problem here is that the Product Managers can get tied up in functionality and requirements. They can spend so much time building products that there is no-one engaging the customers to understand their problems; no-one looking ahead and strategising as to what the business needs to do in the future to continue to be successful

To drive the maximum success from a Product Management team, you need to understand exactly what their role is.

A successful Product Management Directorate looks at the needs of the entire business and the entire market.  It’s broadly comprised of three main focuses:

• Product strategy
• Product marketing
• Technical product management

The Product Management Directorate will focus the product management team on the business of building solutions for needs now and into the future.  The team will:

• engage and communicate with existing and potential customers
• articulate and quantify market problems
• create business cases and market requirements documents
• define standard procedures for product delivery and launch
• support the creation of collateral and sales enablement tools
• train the sales teams on the product

Within the EdTech market the truth is: if you want better products in the future, and for the product management team to be held accountable at organisational level, then it must be represented at Board level in its own right.

“Your scientists were so preoccupied with whether or not they could, they didn’t stop to think if they should.” Jurassic Park, 1993

Sound business advice there. Just because you can build it, it doesn’t mean you should.

So why do so many tech companies go all Jurassic Park on us and stuff their solutions with things their users really don’t want or need?

I see it happen a lot in my industry – the Edtech sector – ultimately to the detriment of the company and their clients. If you want to avoid this pitfall keep these 3 things in mind with everything you develop:

1. Keep it simple to begin with and create a product which deals with a specific Big Problem
2. Keep focus but keep iterating, all the while solving bigger, related problems
3. Constantly refer back to the vision of the Big Problem that will be solved. If it doesn’t help don’t do it!

One of the key responsibilities of a Product Manager is communication.  Not only being the voice of the customer within the business but helping shape the overall solution from the product to the wrap around services.  Product Managers also need to be able to communicate to the market on behalf of the company as to the direction the Product is travelling in.

One tool for doing this is the Product Roadmap; traditionally this has been a high level visual representation outlining all the features that you want to deliver and by when. Your confidence levels were dependent on how close in time the release was, which meant any features due in 1-2 years time did not inspire the same confidence.

Here are a couple of suggested ways to build your Roadmap and give you and your customers more confidence:

1. Focus on objectives – An alternative way of communicating a roadmap is rather than focusing on features, set out the objective of what the features you are delivering are going to meet, along with how you are going to measure these objectives. This is a good way to communicate to your customers what your goal for each release is, yet at the same time giving you the flexibility to change the best way to meet the objective. One of the positives of working in an agile environment is that you can learn as you go along and change direction quickly, with little impact on the overall delivery of the solution needed by customers. It doesn’t make sense to promise a feature 1-2 years in advance market needs may change but the objective should stay consistent, whatever the solution is. If you are confident of some of the features you are developing you can use these in your roadmap to offer examples of how you are going to meet the objective.
2. Product Strategy and Vision – Before building the Roadmap, make sure you can describe your Product Strategy and that this meets the overall Product/Business vision.  Another reason to use objectives is it should be easier to describe goals from the strategy, rather than just communicating features. When communicating the Roadmap, each individual strategy should be a coherent story, each objective should be building on the previous objective and so on until it fulfils the overall vision. Otherwise ask yourself why you are developing an objective if it doesn’t meet the overall Product Vision for a solution?
3. Keep it simple – It will be easier for your customers to understand if you keep it simple and focus on objectives rather than a long list of features plus also it is easier to update in response to market demands or changes in the overall business vision.  If you have low confidence on the timeframes, then express this in your roadmap, you do not want to be known for not delivering on time.

Do not forget the roadmap is an opportunity to excite your customers, so be imaginative on the design.

Perfectionism is just Procrastination in disguise . . . and Procrastination will kill a product release stone dead.

You see this happen all the time in software, and unfortunately Edtech is no exception!   Companies aim to only release a 100% perfect product because they fall into one of these traps:

1. They honestly believe they can create an amazing solution through ‘thinking things up’ in their office/bedroom/ivory tower.

What they really need to do is get their solution out into the real world to see if it really meets the customers’ needs.

2.  They’re scared of messing up so spend a lot of time strategizing to try and ensure they don’t fail at all.

The truth is the only way anyone can create an amazing solution is by putting it in front of your customers, getting feedback and learning from it.

The problem is that all this Perfectionism is bad for business.  Waiting and waiting to release what you believe to be the perfect solution simply allows your competitors to gain feedback, make improvements and win your market.  All you need is a Minimum Viable Product (MVP) to take to market and an open mind – the customers will tell you exactly what you need to do to create a perfect solution!

Photo by Braydon Anderson on Unsplash

For many software companies there is a real challenge in continuing to develop the software to keep pace with changes in their sector. To be successful you need a business strategy that makes sure you meet the needs of customers in your target market . . . and it’s here where Product Partners play a crucial role.

Product Partners are different to straightforward channel resellers who include your software in a portfolio of other solutions to sell to their target market. Instead, Product Partners have created software of their own which adds value to your existing solution. They can help you to offer a functionally-rich solution, create better revenue opportunities, position your company as the strongest supplier, and create new active and passive income streams.

There are four main different types of software Product Partner, all of which need to be carefully managed to make the business successful:

1.      Advocate partners – this is where you would recommend a partner product and company to your customers in return for remuneration, but would remain in control of the sale from proposal through to closing. It’s a low-touch partnership to add value to your solution.

2.      Strategic partners – these are high-value relationships between your company and the Partner, working together for common goals and revenue-share incentives and aligned around the same values and messaging.   This involves working in true collaboration and allows your business to position itself as a leading supplier in a given deal.

3.      Technical partners – partners who pay a fee to pass information between their product and your product, but their product does not feature within your portfolio. This can represent a separate but active revenue stream for your company.

4.      Referral partners – you would pass leads to Partner companies in exchange for commission remuneration, either per lead or per sale, and allow them to lead the sale through to closure. This is more of a passive income partnership where you are allowing partner companies to capitalize on your customer base in exchange for % revenue.

Whichever Product Partner strategy you go for (and it can easily be a combination of all four) it’s important to keep the main goal of any partnership in mind; both sides must get value from the relationship.