A few weeks back I wrote a post about the kick off of a Digital Workplace project, encompassing synchronous collaboration (such as live chat), asynchronous collaboration (document sharing/collaboration) and project planning/management. I wrote about two strategies that jumped to mind – using a Solution Selling approach to drive adoption (noting that the tools we’re looking at are already freely available, if not readily used), and to ‘dogfood’ the tools within the governance group before expanding out to ‘real’ customers.
Today I want to add a third strategy – applying a startup mindset and principles to what is an internal IT project.
We’ve been using an agile approach in the project to date – two week sprints, regular standups, kanban boards and iterative releases of usable MVPs, but this last point is where things get interesting – in a situation where we’re using nothing but SaaS tools, what is the product we’re ‘selling’?
After a few good discussions with the project team, I think our product can best be described as:
- the technology platform we agree will best meet the needs of our customers;
- the implementation services we offer to help our customers make best use of the tools; and
- the support services we offer for customers once they are up and running with the tools, whether that be delivered by the support team directly or via an active user community.
This is where I reflected back on my days working for a rapidly growing tech services startup, and realised that this situation has a whole lot in common with that startup. As a project team, we are, in essence, a channel partner providing professional services for the tech platforms that we think are a good fit our internal market.
…we are, in essence, a channel partner…
So what does this mean in relation to the principles we could apply within the project?
Representing only the best tools for our customers
Once more thinking back to my past life in a tech services company, I remember a situation where we had two comparable products that were both attempting to do similar things, and we were looking at where to focus our scarce resources in terms of partnering with one of them – supporting both would have stretched us too far. One product had already gained some market momentum, and in its day had a rich feature set that was rapidly heading towards best-in-class. The other had promise, but was nowhere near feature parity and didn’t look like making up the ground any time soon, and even though it had a small, strong following, we cut it loose to focus on the former. In a similar way, as a channel partner we need to make sure that we’re representing tools which will do the best job – definitely now and ideally into the foreseeable future – for our customers, and acknowledging that supporting all the possible tools we could use isn’t feasible within the resources we have on offer.
This is where the value of having solid user personas and user stories comes into the equation – these are the litmus tests that need to guide who we partner with to give our customers the best experience possible.
It is also where we see the benefits of being a channel partner in comparison with being a software platform development company (who tend to be the focus of most startup literature) – if the product isn’t the right fit for the client base, then swap it out for one that is as quickly as possible.
Finding a product evangelist who can make the tools sing
Back when I was consulting, I always went in to sales/implementation situations with a very clear two pronged approach – identify the resistors and show them the path of least resistance to adopt the new tool, and identify the innovators and whet their creative appetite by showing them the outer limits of the capability of the tool.
To do this requires someone who not only knows the tools inside out, but who can quickly apply problem solving techniques at either end of this spectrum to capture the imagination or reduce the anxiety of potential customers – and be able to do it on the spot, and ideally on stage in real-time.
It also requires someone with an infectious sense of enthusiasm, a great sense of empathy and I’d argue a genuine belief that the products on offer can make life better for customers. They are the public face of the better world on offer for anyone willing to listen to their story, and they are worth their weight in gold to any startup – including ours.
Designing for scale
One of the very early challenges the project team have had to contend with is being a victim of their own success. As word has started to spread that these tools might be half way decent and that there is a team looking at how to make best use of them, so have the requests to be involved and get support increased.
Already this has threatened the ability of the team to deliver consistent, high quality service to potential customers, so one of the challenges now is to look at what we know from our early deployment of the tools (to the Governance Group as I discussed in the previous post, and to some other pilot groups) and then understand how this could be designed to scale. My question to the group was that if we had one hundred, five hundred, however many new customers on our doorstep tomorrow morning, then what would the process and resourcing look like in order to get them all up and running quickly without sacrificing the customer experience? There is no point in having rapid customer growth if the customer experience plummets because of a lack of scalable services – this path leads nowhere good, so there is value in thinking about this early in the piece.
This is akin to putting a focus on tuning the MVP in Lean Startup terms, but tuning it for the future as well as for the now.
Accelerating the feedback loop
‘Build, measure, learn’ is one of the tenets of the Lean Startup methodology, and it applies in this situation just as much. This applies to the tools themselves (including frequent testing against personas to ensure that the platform represents the best spread of tools possible), the implementation methods, and the support services on offer.
A great example of this happened in our very first virtual governance group meeting. Of the dozen or so people in attendance, all but one had been through a lightweight ‘tech readiness’ check with our product evangelist. The result? All bar one – and you can guess which one – had a seamless connection experience on the day of the meeting. The one who didn’t have the check felt rushed, stressed, and needed a ‘rapid response’ visit five minutes in to the meeting to fix what turned out to be a minor tech problem. The learning? That a quick tech readiness check as part of the implementation plan would appear to be a very sound investment in terms of getting customers off on the right foot when it comes to synchronous interactions.
This feedback loop needs to be a responsibility of all project team members, whether they are customer facing or not. See something, say something, and do it quickly – the earlier a required tweak in product or process is identified, the quicker it can be applied.
Having an exit strategy
Let’s be honest. Nobody likes that project which goes along hammer and tong in its own world until go-live, at which time the project members throw the whole thing over the fence to the support team as they vacate the premises post-haste. Nobody. So just like with any startup worth it’s dues, it is important to at least in some way be thinking about what an exit strategy might look like.
There’s value in considering all options, but the most likely is that the IP generated within the project – including the specialist platform knowledge and the implementation and support methods – will be handed over as part of a sale to a ‘friendly parent company’, the IT department. This means considering early on in the project whether the ongoing support resourcing will still deliver value to customers in a sustainable way. There’s absolutely no point in having a platform that needs premium consulting services to be successful if the cost of delivering those service isn’t sustainable.
After all, in the words of the Lean Startup methodology,
Startups exist not to make stuff, make money, or serve customers. They exist to learn how to build a sustainable business.
http://theleanstartup.com/principles
Internal IT projects like ours may not be startups, but they can certainly learn a lot from them along the way.