23: Building a successful software company | Seven reflections from the foothills (Part 1)

In this week’s blog, I am going to take another – somewhat philosophical – detour from the current thread. This week I provide an update on where we are with the Method Grid journey and take a reflective muse on the challenge of building a successful software company.

For those of you involved in a software startup or reading with a vision to develop a software business (business application especially), the aim is to pass on our major learnings thus far: tactics that worked, tactics that didn’t, some bear traps to avoid and a general catch-up on what we know now that we really wished we had known from the outset!

Let’s start with our exciting update.

As of last week, after two years of part-time collaboration, the Method Grid development team has moved to a new phase of full-time commitment to the endeavour.

For Ian (our lead developer), this involved resigning from his employer of eight years; for Jody (web developer) and Tom (designer), both self-employed contractors this has involved paring down their (very successful) client portfolios. What this team has achieved hitherto in the margins of busy lives – essentially in evening, weekend and snatched hours here and there – has been remarkable but the time has come to shift gears. In coming weeks (aiming for June 2018), we will move to a commercial version of Method Grid and, thereafter, we seek to accelerate the development of new features that our cherished beta community desire most.

The last few weeks have been filled with all of the niff-naff of company start-up: incorporation, bank account setup (how long does this take nowadays!), insurances, accountant retainer, legal documentation etc.

It’s a big moment emotionally and, clearly, we now enter a new phase of entrepreneurial risk (incumbent as we now are on funding salaries and other business overheads). It is also a moment charged with energy and anticipation, a reminder of why we entrepreneur: the privilege of working with brilliant colleagues (and clients), the present-day-of-learning and the journey-now as much as any distant, elusive destiny.

Building a successful software company

As such, it feels like an appropriate moment for the briefest of operational pauses – to stop and reflect on the last two years.

I have spent most of my career learning how awesome professional service (PS) companies work; having built (and sold) my own PS business and then subsequently providing non-executive, advisory and training support to hundreds of other such firms, I would go as far as to say: professional service entrepreneurship is my specialist area.

Conversely, building out a software company is not!

The Method Grid solution really talks to professional service firms – but – whilst this provides some succour, it doesn’t negate the fact that building a successful software company is very different from building a successful professional service firm!

As an aside, for business leaders seeking to do both concurrently this observation really deserves emphasis. I have noticed many a company drift towards growth stasis and erosive managerial ambiguity when it attempts to do both in equal measure. The duality is possible (albeit no doubt very challenging – as the major point still stands) when one aspect is a clear strategic slave to the other.

So, before I begin with the seven reflections on building a successful software company please note the important context. We have not – yet – built a successful software company! Rather, with some humility, we stumble out of some early foothills with an intimidating summit ahead. Notwithstanding, for those still in the car park, loading up their rucksacks and checking their maps, we can maybe pass on a few useful observations from this viewpoint.

---

Reflection 01: On release of Method Grid v1 we should have listened harder and moved faster.

Following first concept meetings in March 2016, the first release of Method Grid appeared in December 2016. As any parent of a newborn can testify to (talking of nine-month gestations) we were wildly proud of it.

Our newborn was shared with a small set of acquainted companies (c. 40) and immediately we started to get a sense of its imperfections. At one level, the product looked beautiful and for a first iteration there was plenty of user support assets (videos, FAQ etc) but the feedback we received was along the lines of: “guys … we love what you are trying to do conceptually … it definitely address an issue we want to solve … but boy it is complicated to use”.

At the heart of this poor user experience sat a couple of quite fundamental user experience (UX) design flaws. Before anyone could create an element (our key unit of knowledge capture), they had first to create an element template, then reference the template to populate it. Additionally, all of our key user actions were tucked away in menu structures. The whole thing was just too obtuse and there was confusion as to what was an element template and elements proper – the difference was far too nuanced for many.

We heard this over and over but the – now very well researched – cognitive bias of cognitive dissonance (the more you invest in your plans, the more unwelcome you will find data that infers such plans are unlikely to succeed) kicked in. Like the irrational agents we all are (despite every effort to convince ourselves otherwise) we initially dismissed this growing perspective as user chatter: “once our users get to know the product better they will get over this minor hurdle” type rationalisation.

It was only when, some months into this trial, that we we watched a struggling user experience captured in a video lab that it really dawned on us how flawed version 01 was. It was a genuine head-in-hands team moment. From which point, we immediately set to task on a wholesale redesign and rebuild of the application – giving birth to the action buttons (and the vastly improved UX generally) you see today.

So, with reflection, far too much time passed to get to this fundamental back-to-the-drawing-board moment. We really should have realised this sooner – valuable time was lost.

The key message to others? You will never get it right first time – so – fight against any emotional attachment to early versions. As soon as your minimal product is out with a respected group of testers – go into acute observation and listening mode. If the product is not instantly intuitive, the answer is not more detailed FAQ, additional help videos or explanatory phone calls – it is a fulsome redesign and recode! This knowledge – if you act on it immediately – is as constructive and valuable a moment as a universal thumbs up from your beta testers.

The video capture of first time users is gold dust. Product developers all get way too close to their respective applications to be able to objectively appraise usability – watching (with separation) virgin users grapple with your clever-clever interface, heading down multiple false process lanes, is searingly insightful. Be sure to use this tool early on.

---

Reflection 02: You can get a long way in part-time, low-cost mode!

I recently had a coffee catch-up with a respected business leader. His consulting firm has, in recent years, largely pivoted away from professional services towards a business software focus. Their core product has been many years in development – with a full-time team of outsourced coders; he estimated the invested development spend to date as c. £1.5m. He envisaged spending half again to really get the application to a place he was happy with – truly meeting his early (SaaS) clients’ expectations.

I shared Method Grid v3 with him. “How much have you invested to date?” he asked. “In actual incurred costs …”, I answered, “… less than £5,000”. He nearly spilt his coffee down his shirt and, after closing his agape mouth, confessed that he believed our product was further advanced than his own.

The point I seek to make here – is not that there is a right or a wrong way to get to this end-of-free-beta-trial stage; rather, that there are options for the day one entrepreneur. Contrary to the gung-ho, throw-all-my funds-at-it approach, you can, and should, consider different (risk-profile) routes through the foothills.

To illustrate, let me describe how the Method Grid team arrived at this juncture spending less than £5,000. Once we (me, Tom, Jody and Ian) had collectively decided that the proposed project was an intriguing one, we agreed a simple sweat equity agreement (captured in a simple Memorandum of Understanding). Essentially, we all recognised that early work was mere hypothesis testing and could easily come to naught. If, however, the product met a genuine need (as validated by real-world beta companies) then, and only then, we agreed – we would incorporate a NewCo per the MoU i.e. sweat equity would crystallise into actual equity.

We then all worked on the project in the (busy) margins of our day jobs: primarily evenings, weekends and occasional “days off”. We have not spent a penny on marketing; rather relying on personal professional networks and frequent content blogging (that talks to our core user market) to build the beta community.

This approach brought many advantages.

Firstly, there was no wasteful time-money burn when the latest product release was out with our beta community being reviewed. You can’t rush these phases (essentially pauses in the development cycle) so it was a relief not to be burning through salary cost (as per many early-stage software companies) effectively in pre-revenue, waiting-for-market-reaction mode.

Secondly, we only had to worry about all the distraction of company incorporation and operational administration at the point when we (a) had a product and (b) had data to show that the product had a market.

Thirdly, we cross this threshold with no debt and/or equity dilution! We can’t tell you how good this feels. Now, of course, debt and/or equity dilution is not, of itself, a bad thing; at points on most company build journeys, well-placed fund insertion is – of course – synonymous with capability and growth inflection (especially so when it comes with relevant expertise). The reflective assertion is, rather, that our route has allowed us to defer this point to a time when our company is worth far more (which, in turn, equals less founder dilution).

Of course, the route just described is not without risk. In our part-time, lean-team mode, we could easily have been overtaken by fully-funded competitors (an ever-present risk). With some software ideas, a multi-horse race is invariably won by the team that moves from accepted-concept to finished-product the fastest. In such a strategic field, there is no place for the timid, steady-as-she-goes entrant. With, however, a more esoteric, niche entrepreneurial pursuit you might want to consider a similar path.

That is: fight lean initially and save your pennies for a day when you genuinely have market evidence to back your founder’s hunch.

---

Reflection 03: Use your own product!

Method Grid is designed to help organizations capture, structure, share and continuously improve common operating procedures, methodologies, process roadmaps etc.

Having spent most of my career in professional service firms (most of whom really struggle to do this well), I intuitively understood the user-case for this platform. Of course, it was why I conceived of it in the first place! My founding colleagues, however, coming from different career paths (design, coding, software support etc) were less familiar with this organizational requirement. To a degree, they had to take my word for it.

For a long time, as a team, we spent a lot of time working on the product but rarely in it (incidentally, the opposite sin of most company leaders). That is, we were responding solely to the feedback of other users in our platform – in terms of what next to improve.

A critical moment came when, on one of our team chats, it was decided we could really gain from the actual use of an account in our own product (cf. just using it as a demonstration account). There were, of course, even for a small, fledgling team a number of grids (our term for procedures) that we needed to capture. The moment forced the whole team to really understand what it was we were building; a shift occurred from intelligent technologists implementing a user specification to a myriad of actual-user “aha” moments.

The gain of this is immense; now the whole team are constantly and proactively spotting new improvements, new ways to enhance Method Grid yet further.

Indeed, we have recently stepped this practice-what-you-preach ethos up to another level. Whilst we all love our collaborative cloud-based tools (see future reflection), we have essentially adopted a “can we do it on Method Grid?” first filter. If the answer is even “possibly” then the gain from such attempted use is immense – triggering as it does another round of potent design discussion: “if we were just to tweak/add this – then Method Grid could also do this – would also compete against X”.

By example, we recently used Method Grid to plan our forthcoming team summit (an exercise we would usually do in Google Sheets or Excel) and found it perfect for this level of scheduling: elements essentially representing individual session modules that we could quickly label and drag/drop into different time blocks (grid framework), elements can then store the additional dimension of session notes and links. It is one example, of many, that has spawned innovative ideas as to how the platform can evolve, how we can enrich the user experience.

The generic reflection: if you are developing a software application then use (in a real world manner cf. contrived) what you design and build. Do this as a whole team affair as only then will you truly see it as your users see it and only then will you fully grasp the driving wheel of your product’s future path.

---

So, what’s next?

Next week, before returning to the thread on how to build a sales capability in a professional service business, I will conclude this pair of essays with the second part of my (out of the foothills) reflections on building a successful software company.

Hopefully, you’ll join us on this journey. It’s totally free, and you don’t have to be a Method Grid customer (though you’re more than welcome to sign up for a free trial here).

We’ll be releasing a new post each week. To get each post emailed to you as soon as it’s published, sign up for the Climbing Mount Audacity mailing list below.

Climbing Mount Audacity…
From Startup to Scaleup!

We're sharing everything we know about how to build an awesome professional service firm (and enjoy the journey en route!) PLUS travel updates, reflections on our stumbles and general musings on our Method Grid journey.

Signup below to get the latest articles
direct to your inbox.

See you next week. Have something you want to hear more about? Let me know in the comments below or via Twitter.