Little House Consultancy

07971841992

We help ambitious companies with the strategy and management of their software, organisational and development projects.

Recruiting Developers

I've been asked a couple of times recently about recruiting developers. I seem to be writing the same email many times, so I thought it better if I put my thoughts down here and could just point people to this in future! 

There is a big difference between recruiting during the early stages of a start-up compared to once you've built a successful development team and business. The first few recruits are so key to the success of the business that there is a different driver and reason for who you choose to hire. They need to be experts in their field, passionate and motivated, which means your pitch must be pretty darn good. And by pitch, I mean why anyone would want to join you in your dreams of turning your idea in to a successful business. This is where Employee Value Proposition (EVP) is focused on the intrinsic rewards. It's not rocket science... what would get you excited... the latest tech, a focus on quality, working with experts, being involved in the decisions, a level of responsiblity and autonomy and clear benefit to progressing your career development! And don't scrimp on wages. If you really can't afford to pay top dollar, then you will have to look to compensate with share options! I firmly believe one good £50K developer is worth much more than two £25K devs! I'm not saying all these things aren't important when you've established dev team, but often you'll be looking for a more run of the mill hire... someone to come in and fit in, pick up an existing project, work through a task list, not make waves, set direction and re-architect a perfectly good platform. 

Now let's tackle the obvious issue... I wouldn't call it the elephant in the room, more the racist old relative in the corner that everyone wants to ignore - recruitment companies! I'm not saying they are all awful, but most don't seem to add much value to an already difficult process. All I would say is try recruiting direct first. Recommendations are best... offer an incentive for current employees to introduce someone (e.g. £500 if they pass probation). This is even more important for those intial hires as they are so key. Put the job on your www and tweet etc. Being based in South Wales, DigitalProfile.io worked well for me recently. We also recruited via Cardiff Dev slack group... find similiar in your area and get the job mentioned.

Finally, recruitment companies... you will have a multitude of options, choose the recruiter who really takes the time to get to know what you need. I want to receive 1 or 2 good candidates not 10 rubbish. Volume is not good! I want a recruiter who filters the crap out. I was lucky to find a recruiter who could predict who we would hire... If he said we would like them we ended up employing them!

There is a difference between the job advert and the job description. One is selling the company to attract applications from the right people and the other is an internal document that clearly defines the ideal candidate. The job description can be used to rate candidates, but is also good for future appraisals. Try to define the attitudes and behaviour of the ideal candidate... people can be trained to acquire skills, but it's difficult to change a person's attitude!

Telephone interview before a face to face. Write down 5 questions to ask each candidate. Explain to them that it's a short 5 to 10 minute chat just to avoid wasting each other's time. Schedule calls 20 min apart and plough through them. Mark each answer.  It is amazing how often the candidate with the highest score ends up getting the job after the face to face. You'll be able to discount the time wasters very quickly allowing you to focus on the real candidates.

EVP - employee valuation proposition. It's a big area! Pay is not everything. Virgin airways pay half of British airways for air hostess but which company has a strike. Same for Admiral... they pay 20% less, have half the churn rate and are regularly voted best employer! Get EVP right and you don't have recruitment problems. Work out what the benefits of working with you are. I like to ensure devs are allocated time for personal dev. Not only do they feel their skills are progressing, but you get people in to the habit of researching technology. I want tech decisions based on sound facts, not just because "its what I always use"!

But pay well. Its worth repeating.... a £40k dev will be more productive than two £20k. Importantly they will be able to tackle more difficult problems. Which brings us back to the job description... define what you need. Do you need an architect to make the big decisions, a lead to ensure quality and define work, or a builder to plough through already specified work. Look at other comparative job adverts and see how you compete. Then set expectations with the FD 

Some thoughts about Onboarding

There is often such a race for getting more and more leads that the conversion of these leads to becoming paying customers is often sidelined. In fact, even that statement is wrong. Really you want to see how many of your leads are paying for your product 6 months later! That is the metric that determines whether your business will be successful and make money. 

This blog post is more of literature review... I've brought together some useful links to read about the customer onboarding process. I've tried to pull out a few of the key statements (and occassionally edited them to make them read better out of context). I would still recommend reading the full article in each case.

As a summary, I think the key takeaway is to put yourself in to the shoes of your potential customer and make every effort to ensure they can achieve their goal. You aim of getting money out of them will then follow. 

http://sixteenventures.com/customer-onboarding

What does a successful Free Trial looks like for your prospect. And no… it’s not “they convert to a paying customer.” That’s YOUR definition of success; don’t confuse that with THEIR definition of success.

A customer is “onboarded” once they’ve achieved “initial success” with your product - consider this First Value Delivered (FVD).

Since your customers will achieve success on their own cadence, having a timed autoresponder sequence – when the technology is readily available to trigger based on milestones reached – is just irresponsible.

http://clementvouillon.com/article/why-a-good-product-onboarding-is-important-for-saas/

It is important not to mingle product onboarding with a traditional “help”.

Options:

  1. Passive tour
  2. Active Tour
     http://www.appcues.com/
     https://www.nickelled.com/
     
    https://www.walkme.com
  3. Video
  4. Slider explanation
  5. Explanation within interface


https://www.groovehq.com/support/great-examples-of-customer-onboarding

Don’t worry about secondary features or non-core integrations in the onboarding process. Leave the user something great to discover about your business later on. For now, focus on getting them engaged enough to want to learn about those extra features.


https://blog.intercom.com/strategies-for-onboarding-new-users/

Clear path to completion - numbered steps!

Connect to team - encourage to get other users onboard.
    Do it early if they need their team
    Do it after WOW if not!

 

https://blog.intercom.com/onboarding-users-low-hanging-fruit/

The purpose of a trial is to convince a potential user your product will deliver what they need for a price they can afford

1) Understand the different jobs your product is hired for

2) Understand what success looks like for each of these jobs

3) Design a path guiding them through the features that help them achieve this

4) Communicate with users to help them get there

5) Have an early warning system for new users

 

http://www.appcues.com/blog/why-user-onboarding-is-the-most-important-part-of-the-customer-journey-by-2.6x/

  1. Short-Term Retention—Week 1: Use the product more than once
  2. Mid-Term Retention—Week 1 to Week 4: Establish a pattern of usage
  3. Long-Term Retention—Week 4 and beyond: Rely on the product as an indispensable tool

You see such rapid drop offs in retention in the short-term phase—people can’t find the value and churn out immediately.

This recognition of core value is called the WOW Moment.

 

Other Reading

http://www.appcues.com/blog/optimize-user-onboarding-slideshare-tips

http://www.evergage.com/blog/9-biggest-customer-onboarding-mistakes-avoid/

https://www.entrepreneur.com/article/273124

 

 

What does MVP mean?

Minimum Viable Product - what does that mean?

(This article brings together all the recent posts about MVP - mainly so I can share one link!)

If you have had the (mis)fortune of working with me on any product development projects you’ll know that I’m quite a fan of Amy Jo Kim (http://amyjokim.com/) and her approach. Her “core loop” can be considered the minimum structure that the user needs to feel satisfied they have completed their task. The focus on identifying core loops is more than just the starting point for your product, it should be the key insight that you return to throughout the lifecycle of a product’s development. This article builds on this and tries to look at how the whole team walks through the subsequent building blocks that ends with a fantastic product.

The end goal of a development project is obviously to release a product, but there are key stages on this long route that should be considered as project goals in themselves. To take a leaf out of the Lean StartUp book, there should be a series of tests with the aim of each one to capture some specific learning goal.

I like the idea of developing a “minimum” item to test. It implies that it is the smallest item needed and should therefore be easier to make than anything bigger thereby reducing wasted effort. This is only true if you know the purpose of what you are making – and then test that it satisfies this purpose! Too often I hear the term Minimum Viable Product being used when it’s inappropriate. It gets used as a catch all statement to replace the work necessary to define the sub-project or the test’s goal. Different people will have different definitions of an MVP, and worse, they will internally change their definition over time. As is often the case, there is a lack of communication. The definition should be made public and be clearly defined for the whole team to agree on. I hope this list of sub-projects or tests will act as examples and replace the catch all MVP. Each has a purpose; each provides a specific learning objective or function. As is the nature of a list this is going to look like a waterfall project plan – please do not take is as such! The definitions on the list are to provide a series of defined targets that can be used as tests. Use them as guidelines to make your own – just make sure it is clearly written down and agreed by the team. 


1) Define your core loop

http://getting2alpha.com/downloads/Getting2Alpha_Breakthrough_3-Game-Thinking-Blueprint.pdf (TL;DR - At least read page 8!)This is the repeating activity that your customers carry out that creates value. It is also an activity that they can “improve at” when using your product. I would highly recommend reading / watching the extensive list of material that Amy Jo Kim has created. My only additional comments are that this “step” is focused on the business (after all it is “core”) rather than the technology. It can also be relatively tricky to pin down in start-ups, and because of this it should be tested early! It might also take several iterations to get right - in fact it might not be until several of your next minimums have been created and tested before you settle on a final core loop.

2) Minimum Walking Skeleton

http://alistair.cockburn.us/Walking+skeleton
If the core loop was focused on the business aspect of your product, the walking skeleton is focused on the tech! It’s the minimum architecture that links together the key building blocks of your system. It’s not meant to be your final architecture, its meant to show that at the most fundamental level you can make a coherent working system.

I often see examples where a tiny string of data is “passed around” the system. Its advantage is that you can then build out, tackling the riskiest or most worrying architectural features – for example adding authentication/authorisation. It’s a useful first target for the dev team as is it gives you the confidence that you have “something working” very early. The problem then becomes one of prioritisation!

3) Minimum Viable UX test as prototype

A key early goal for a start-up should be the creation of a concrete example of your “idea”. How are you actually going to solve the problem you have identified and make it a reality? You then need to get this example in front of real people (not friends!) and measure their response. This could be as rudimental as some pencil drawings (although I do like using tools such as Pop or marvelapp)

Without this key stage, there is often a lot of hot air and handwaving when the founders try to explain “how it’s going to work”. I think this goal has two outcomes… 1) it forces you to focus on the practicalities of your solution 2) it’s the first chance for real feedback about whether your idea adds any value. Previous to this, any feedback you received on your idea will have been made on their assumptions and imagination!
Don’t expect to get the first prototype “right”, but you should hope to see people confirming that you are solving a problem for them. If not, you may want to reconsider your idea!

It is key that you use this artefact to iterate your idea – it is much cheaper, quicker and efficient to change now! This minimum is also probably the first chance for you to get real feedback as to whether your core loop is right/valuable.

4) Minimum Viable UX test of code

If you’re confident that you know what your building, for example the previous minimum received good feedback, a very useful staging post for the dev team is to build a working version in code. Whilst it gives the team a concrete goal it is still important to agree what “works” and what is mocked? There may be no need to “login”, or data isn’t actually saved to the DB – whatever works for the dev team. This has a useful side-effect that the non-coders of the business get a handle on what really works and what doesn’t. There is often a big list of “missing items” after reaching this goal that form the basis of a priority list that will enable the next minimum to produced.

5) Minimum Viable Demo to your “Super Fan”

Think of this minimum as a sales pitch to your super-fan. What needs to be demonstrated so that they want to use it now. The detail of this minimum depends on the nature of your relationship with the super fan. At one extreme this could be done using the same artefacts as the UX prototype, at the other, they may expect to be using it the next day (see minimum 7)!

You are really after feedback that confirms you are on the right tracks for a viable business. The earlier UX test tends focus on the practicalities of using the software, but you also need to find out whether a business will find it useful. You want to leave this demo with a commitment from the super fan to use a working version of this demo. I have several personal examples where the commitment never materialised. “If it just did this one extra thing” is an easy way for someone to postpone telling you the truth that in fact they don’t want to use your product, which in its own way is hiding the real statement of “I don’t value your solution”.

6) Minimum Viable Product for your “Super Fan” to use

This is probably the most important Minimum to define and build. It allows you to answer “Do any unforeseen practicalities affect your value proposition?”  

What is truly needed for a single individual to road-test your brilliant solution to their problem? Be ruthless, focus on the core loop. Why build Dashboards when you haven’t even worked out how the core functionality works?!?! This is the hardest “minimum” to build, but could very well be the crux of getting your product to launch! The key point of this “minimum” is that an end user can perform the real world activity for themselves.


It can be quite contentious as whether something is needed or not… keep focus on the key user of the system - the persona who gets the work done. You might need some reports, bells and whistles and USPs to push someone to buy your product, but if doesn’t actually do the core job well you might as well forget it for this target.
A useful example is to look at an existing product and retrospectively see if you can see what would have been needed to create this “minimum”. Take “twitter”: no need for notifications, no need for DM, no need for embedding images or tinyURLs. In fact, a true minimum would have worked with an imaginary list of “follows”. All you would need is the ability to enter some text and “tweet” it, and then the ability to see a list of the other “virtual” user’s tweets.

7) Minimum Viable Product for your “Super Fan’s” Company to use

This is the logical step after you’ve gained the commitment (and the enthusiasm) from your superfan to use your product. Focus on what needs to be added so that more than one user from the company can perform the task. It’s likely to be login (and the associated authentication, authorisation issues), filtering data by user, basically multi-user functionality. There is still very unlikely to be the “need” for reporting and advanced dashboards. You can create the users manually in the database if needs be…no need to worry about “admin” or “settings” pages yet!
 

This definition is the minimum that I default to when someone says “MVP” without any further clarification. It has a real focus on the bare bones of what is needed to solve the customer’s pain point.

From this point on, the driver for expanding the functionality should be taking feedback from the users as a primary influence. You still need to stick to the vision of the product, but the minor alterations in direction are best influenced by those people that actually perform the job. It is at this point that the Product Manager / Owner role becomes so key… but that’s for another post!

8) Minimum Viable System for 10 alpha customers

This is where the practicalities of being a new user becomes key. You are starting to think about expanding the user base and the problems that this causes. I rarely find people properly define the requirements for this stage of the business and fall foul because of it. The first few users should become your evangelists, but if they have had an awful time getting started it isn’t going to happen. Using the phrase “it is a beta” only excuses so much and rarely the important first moments of the “on boarding” experience.

As a guide, it should appear to the customer that they fill-in an online form, an account is created and they can use the system. How will the new user get started? Should there be basic help available? How do they contact you for hand holding? Now step back and try to impartially answer: How well does the new user get to grips with the functionality?
Aim: To test product feature set and intuitiveness of product. If they can’t get started then it will be difficult to get the answer!

9) Minimum Viable System for initial marketing - get 50 beta testers!

Now the product has a backbone there needs to be a consideration for the business processes! Start to look at automating the onboarding, but with a focus on the experience these new customers have. (It’s worthwhile looking at page 13 of AJK’s roadmap http://getting2alpha.com/downloads/Getting2Alpha_Breakthrough_3-Game-Thinking-Blueprint.pdf - we are between stages 2 and 3). Your aim is to remove the barriers to USING product. Your about to start getting leads and the last thing you need is a leaky bucket once you’ve got them through the funnel.

One of the common areas that can be an obstacle is data import. If your product needs a backlog of data to be present before the user can start to gain a benefit you have a BIG on boarding problem. Find out how you can reduce this need. Look for alternative user journeys to ease the pain during the initial data loading phase. Can you scrape other sources to help prefill/default lengthy data fields? You want to try almost anything to avoid a traditional data import – invariably the source data will be inconsistent and this will lead to crap data in your pristine new system which will only look bad on you! Remember - Rubbish In, Rubbish Out and you’re spending a load of marketing money telling them their old system is rubbish!

10) Minimum Viable System for marketing to first segment

A fantastic core loop is essential but it is not sufficient to make a successful product. The features that are used in a product’s marketing strategy to attract people tend to be delighters and USPs. These are not the same thing as the core loop! I’m starting to step on the toes of those with a lot more marketing experience, but with my technical hat on I want to make an important point. There needs to be some “sparkly” bells and whistles that the marketing team can shout about and that differentiate you from your competitors, BUT they are not endless ! Pick one or two and TEST to see if the market wants them. Don’t just eat up all your dev resource building yet another “nice” feature because you think more is better – it isn’t! Build what works and that means what works for marketing as much as for the user.

11) Minimum Viable Business for growing Customer numbers

As this is the last minimum I want to reiterate that this list isn’t a waterfall plan. However, for any business this is the final minimum they hope to end up with!

At this stage I tend to promote an emphasis on Customer self service (via help videos, scaffolding etc) as you invariably want to scale quickly without the need for lots of bodies to answer the phone. However, it doesn’t take away from the fact that inevitably you’ll need a support desk (or account manager’s or customer success… you get the idea!). What tools have you got to help when things go wrong. Obviously, you want to automate as much as possible, but the point of a minimum is that manual systems will suffice until they don’t – the key is being ready and upgrading your manual processes before they become a problem. Now this is getting in to managing teams of people, but the key insight is to ensure you have evidence to show that time is being “wasted” doing a job manually that could be automated. A simple ROI on the time to build the tools can give you the pay back period.

 

11) Minimum Viable Business for growing Customer numbers

As this is the last minimum I want to reiterate that this list isn’t a waterfall plan. However, for any business this is the final minimum they hope to end up with!

At this stage I tend to promote an emphasis on Customer self service (via help videos, scaffolding etc) as you invariably want to scale quickly without the need for lots of bodies to answer the phone. However, it doesn’t take away from the fact that inevitably you’ll need a support desk (or account manager’s or customer success… you get the idea!). What tools have you got to help when things go wrong. Obviously, you want to automate as much as possible, but the point of a minimum is that manual systems will suffice until they don’t – the key is being ready and upgrading your manual processes before they become a problem. Now this is getting in to managing teams of people, but the key insight is to ensure you have evidence to show that time is being “wasted” doing a job manually that could be automated. A simple ROI on the time to build the tools can give you the pay back period.

10) Minimum Viable System for marketing to first segment

A fantastic core loop is essential but it is not sufficient to make a successful product. The features that are used in a product’s marketing strategy to attract people tend to be delighters and USPs. These are not the same thing as the core loop! I’m starting to step on the toes of those with a lot more marketing experience, but with my technical hat on I want to make an important point. There needs to be some “sparkly” bells and whistles that the marketing team can shout about and that differentiate you from your competitors, BUT they are not endless ! Pick one or two and TEST to see if the market wants them. Don’t just eat up all your dev resource building yet another “nice” feature because you think more is better – it isn’t! Build what works and that means what works for marketing as much as for the user.

Company Number: 09630799 | Contact: richard@tybach.co.uk