Just before Bett this year, Nick caught up with Lawrence Royston, Founder of teamSOS, to talk all things edtech.

Lawrence is one of the true entrepreneurs of the Edtech market. Along with his partner Joanne, he started with GroupCall messenger, the first SMS messaging system for schools in the UK, then built Xporter, supporting Third parties to have a generic way to integrate with MIS data, before looking at how they could provide deeper insights in the data they were already transferring through GroupCall XVault. He’s also supported GDPRis and has recently started a new business in teamSOS, an incident management and compliance tool for staff in Education and NHS establishments.

We’ve split the interview into two parts to make it easier to digest. In part one Nick and Lawrence discuss:

• What it means to have an entrepreneurial mindset
• Working with partners (and family!), their symbiotic skills, and how this is a great asset in business
• The thinking behind teamSOS, where the idea came from, and the problem it solves
• The importance of listening and learning from users
• ‘Successive approximation’ and continually iterating solutions to help better meet the needs of your customers

In part two they talk about:

• What advice would Lawrence give budding edtech entrepreneurs based on his own experience?
• Getting work/life balance right
• The effect of recent market changes: how consolidation makes space for speedboats!
• The innovation bubbling away in the background within smaller businesses that lead on vision and integration
• Modernising technology (case in point: walkie talkies)
• Their approach to pricing and delivering value
• How making school staff feel cared for attracts and retains the best candidates

Enjoy!

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.

“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!

Is it possible to win a bid purely on your ability to meet the requirement?

My opinion is that it isn’t.

In my industry (education/public sector) it’s important for establishments to engage in a fair procurement process, so the ability to meet a technical requirement will score you points.

However, I personally don’t think you’re in the running if you don’t have a relationship with the customer, understand what’s important to them and know why you’re bidding. There’s so much more to it than what’s written in the product spec. It’s your job as a business to understand that. Relationships are everything.

Still, a lot of companies in the sector insist on bidding anyway as they think they have a chance based on requirement alone. To them their product is king (they’re also the people who think “the product sells itself”) but more often than not they’re just pouring their money/resource away.

What do you think?