You produce results: Learn from these

Thoughts on product, process, startups, development | 04 Jan 2015

It’s nearly been a year since I joined Fruitful - a fintech startup that’s working to rethink how savers save and how borrowers borrow.

Since then we’ve been through a significant product redesign, a complete branding overhaul, a successful soft-launch and a customer response that has more than overwhelmed us. With customers investing with Fruitful from all over the globe, it’s clear that people are in search of an ‘alternative’ that offers fair interest rates, secured lending and the flexibility that we should expect from a modern investment product.

So as we venture into 2015, I thought I’d share a handful of the lessons that I’ve learned and have considered tattooing to my forehead.

Mostly product focused, take from this what you will:

Integrate Around Concerns

When working with a team of designers, developers and content people, there’s always a temptation to separate tasks by role, such as a ”design” todo list and a ”programming” todo list.

The problem with this approach is that it’s difficult to assess progress from separate to do lists or issue backlogs. On top of this, there’s an increased operational risk. Since the QA effort stutters, stopping and starting as each role’s to do list is completed, you run the risk of failing to test the feature as a whole.

Learning from this, we’ve formalised a workflow that integrates arounds concerns. Instead of organising around roles (e.g. design tasks, programming tasks), we organise around areas of concern (e.g. registration form, email receipts). As Ryan Singer puts it:

Marking one piece “done” is powerful because it requires design, programming, support and review to integrate around a specific point in the product.

Whenever a list is finished, it shows a piece of the product is ready to review and mark ”done”. It feels great to know one part of the product has no remaining contingencies. It’s ready to go.

Minimum Marketable Product

Give that I:

joined the project just after its inception and
had limited experience in the mortgage market and
was (initially) unsure of its legal and regulatory commitments

I failed to ask some important questions about minimum marketable product (MMP).

And yes, I prefer MMP as it underscores the importance of building something that is sought-after, by customers, (marketable) vs. something that is viewed merely as feasible, by the company, (viable).

On top of this, MMP forces you to:

Think about the important areas where you should adding value (i.e. your differentiators) in conjunction with:
Working hard to develop those areas, so that they reach a high level of finish, giving you a better opportunity to win the hearts and minds of your customers.

Given the choice, I’d always favour a good job of half, than a half-assed job of all. Much later than I should have, I noticed that as a team, we were stretched and chasing our tails to reach our fast-approaching launch date.

After some belated conversations about the product’s essentials, and a hash through our priorities, we were left with a much more slender view of our MMP. As a result, we were able to achieve a higher level of finish with features we developed, we were less stretched, and we shipped quicker.

In short: dream big, implement small.

90% + 90% does not equal 100%

The ninety-ninety rule lassoed us a number of times:

”The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time.”

Tom Cargill, Bell Labs.

In short: be very careful that you do not underestimate the time, effort and energy that the remaining 10% will demand from you and your team.

Deadlines are hard to reach. And they’re even harder when you mis-judge the magnitude of your plans.

Go broad before you go narrow

Common talk in the world of human-centred-design, but this is useful in most walks of start-up life.

When you have to make a decision, go far and wide with your ideas, no matter how daft or bizarre they sound. Superglue the Devil’s advocate mouth together while you go broad with your thinking. You never know what inspiration you might draw from this left field, brainstorming effort.

This method of thinking has helped us overcome some real challenges and produce far superior solutions and ideas.

Effective concepts often draw on multiple sources of inspiration and thinking, and this process will help you along your way.

Finally: on Venture Capital

“It’s all about burn rate, about burn rate, slow spending...”

Fingers crossed I’ll find more time to write and share what I’m learning in 2015. I hope you do too.

Our Duty

Thoughts on process, design, development, code | 26 Nov 2013

Firstly, think about what your pages do, not what they look like. Let your design flow from the services which they will provide to your users, rather than from some overarching idea of what you want pages to look like. Let form follow function, rather than trying to take a particular design and make it “work”.

For us wonderful folk who make websites, it’s our duty to read John Allsopp's seminal A Dao of Web Design at least once a year. For an article that was written way over a decade ago, many of those points still offer so much significance today.

Lazy Loading Responsive Images

Thoughts on design, responsive, development, code | 07 Oct 2013

Learn more below or see the Demo →

Most of last week I was rebuilding a website for a longstanding client. Performance (i.e.how fast the thing renders) is not only important to this client, it’s imperative. A good proportion of their customers live out in the sticks, and as a result, many have slow internet connections.

Lazy Load to the Rescue

To speed up page load, we decided to use the popular Lazy Loader plugin which defers the initialisation of images until they were needed. Most importantly though, users on slow connections would have the (essential) page content loaded almost instantly, while (complementary) imagery could download subsequently.

Lazy wants to know!

The problem: Lazy Loader demands that we define the width and height of our images.

“Note that you must set image width and height either as attributes or in CSS. Otherwise, depending on your layout, plugin might not work properly.”

Since we were using a flexible grid, we knew that the image width was going to be 100% of its context. However, we couldn’t define a height. If we did, when the grid fluctuated, the ratio of the image would impair.

Actually; Ratios to the Rescue

In theory, we knew we needed to define a ratio in CSS. We needed the height of the image to be relative to its width.

I’ve seen a number of JavaScript plugins which enable this, but I was sure there would be a way of using the browser’s presentation semantic, CSS, to do the job properly. This would prevent flashes, reduce load time and help me sleep at night.

Here’s an example JavaScript flash that’ll keep you up all night vs. the fluid / responsive, lazy-loaded image demo site:

The pixie dust

1] We create our markup; a container element which will house our lazy load image:

<div class="panorama">
    <img data-original="/images/example.jpg" src="/images/lazy-grey.gif" />
</div><!— /.panorama —>

2] We define the styles for our container element “panorama”:

.panorama {
    position: relative;
    padding-bottom: 24%; /* our ratio for this image, you can adjust this accordingly */
    padding-top: 30px; /* IE7 fix */
    height: 0;
    overflow: hidden;
}

3] Then we define the lazy image like this:

.panorama img {
    position: absolute;
    top: 0;
    left: 0;
    width: 100%;
    height: 100%;        
}

Here’s what we’ve done…

In short, we’ve created a container element, which, using the height 0 trick in combination with the padding bottom percentage (to define our height) gives us a contextual ratio for our image. Combine this with a cheeky absolutely positioned image with a height: 100%; and width: 100%; statement and we’re laughing all the way home. No flashes on lazy loaded images, no rendering blips and only a few lines of additional code.

If you haven’t already, checkout the Demo →

I’ve made the demo repository public on BitBucket for your downloading pleasure. This has been tested in a whole bunch of browsers but if you run into any problems, drop me a tweet and I’ll see what I can do to help.

Until next time!