Gigster is coming to town….

Melbourne’s Work Club recently hosted Gigster Senior Project Engineer, Catherine Waggoner, in conversation with Venture-Store’s George Tomeski. Part of Startup Victoria‘s Fireside Chats, it likely herald’s Gigster opening an office in Melbourne, to service local clients and to tap into the local developer community.

gigsterFor the uninitiated, Gigster describes itself as the “world’s engineering firm”, that helps clients scope, design and build software, apps and digital products. Using an established product development methodology, and drawing on the resources of a 1,000 strong network of freelance designers, developers and product managers, Gigster is taking much of the pain out of the costing and requirements process for new projects, as well as building a growing client base of enterprise customers.

Not mincing her words, Ms Waggoner opened her remarks by commenting, “The software development industry model is f*#$ed”, because:

  • Requirements are poorly defined
  • Scoping is laborious
  • Development costs blow out, and
  • The whole process is not very transparent and not very accessible.

As a case in point, she mentioned the significant cost disparity between what some digital design agencies or app studios might quote for building an iOS product compared to what Gigster would estimate. By: breaking projects down into the distinct stages of scoping, design and pre- and post-MVP; only engaging the “best of the best talent”; using proprietary tools both to estimate fixed rate costs (rather than billable hours) and to define and source solutions; and re-using content from a library of “Community Software” resources, Gigster is able to deliver quality projects in shorter time, and on more modest budgets. For example, based on the large number of projects that they have fulfilled, their “Gigulator” estimating tool incorporates 5,000 possible features.

From an investor perspective, Mr Tomeski mentioned that the “VC inflexion point is getting much earlier” in tech startups. Meaning, with lower development costs (and potentially, reduced valuation multiples), investors are looking to get in sooner, with lower exposure, but still generate reasonable returns on exit, thanks to cheaper establishment costs.

Of course, Gigster sits at the heart of the gig economy, a huge issue when it comes to discussing the Future of Work. Interestingly, many of Gigster’s contractors are themselves startup founders, who freelance while building their own businesses. But such is the strength of the network, something like 35%40% of their contractors work full-time for Gigster – they like the flexibility combined with the continuity. Many of the contractors are referrals from existing team members, and a number of teams (known at Gigster as “houses” – presumably a frat thing?) have bonded to such an extent that they get allocated specific projects to work on together, even though they themselves may be working in different locations, based on previous projects.

Working for Gigster is probably a career choice for some contractors, because there is a variety of projects to work on, and the opportunity to be involved from start to finish. Which may be the opposite if working in a more corporate or enterprise environment, where work may be routine, repetitive and reasonably narrow in scope.

If Gigster does decide to set up shop in Melbourne (with encouragement from
InvestVictoria) they will be joining the likes of Slack, Stripe and Square, tempted by financial and other incentives. Such a move may challenge a number of local digital agencies, who will face even more competition for talent and customers.

According to Ms Waggoner, enterprise clients represent 40% of the business, and should comprise 60%-80% very soon. Not only that, but the average deal was initially $15k, now it’s more like $100k. However, enterprise clients have a much longer sales cycle. Plus, many innovation teams within enterprises are more like loosely formed groups of niche experts, so they need training on how to think like a startup. When you consider the greater dependency on legacy software by corporate clients (where it may make financial sense to retire some assets and build afresh, but the emotional disruption can be huge…), combined with the greater emphasis placed on after-sales service, Gigster has had to adapt its business model accordingly.

But Gigster must be doing something right. They’ve stopped outbound marketing and prospecting, relying on in-bound leads, repeat business and client referrals. There has been a shift from a sales focus to a customer focus, complete with a dedicated customer success team.

A number of audience questions related to getting VCs interested in your idea: What do they look for? How do they assess opportunities? How far should you go in building a product before you can attract funding? What’s the best way to validate an idea? etc. Much of this is about product/market fit, building the right team, getting customer traction, and executing on your strategy (aka Product Development 101.) As part of her closing comments, Ms Waggoner noted that unlike some of the high-profile VC funds (e.g, Y-Combinator, Techstars and 500 Startups) many VCs are becoming more sector specific, because they prefer to invest in what they know and understand.

Next week: Building a Global/Local Platform with Etsy

Design thinking is not just for hipsters….

In recent months, I have been exploring design thinking, a practice I first encountered nearly 20 years ago (when it was called user-centred design). Whether we are talking about UX/UI, CX, human-centred design, service design or even “boring” process improvement, it’s important to realise that this is not just the domain of hipsters – everyone can, and needs to understand how these design thinking techniques can build better product and service outcomes in multiple applications. Here are three real-world examples to consider:

Curved Space-Diamond Structure by Peter Pearce, Hakone Open-Air Museum, Japan (Photo © Rory Manchee, all rights reserved)

Curved Space-Diamond Structure by Peter Pearce, Hakone Open-Air Museum, Japan (Photo © Rory Manchee, all rights reserved)

1. Financial Services – a case of putting the cart before the horse?

A major bank was designing a new FX trading system, to replace a labour-intensive legacy system, and to streamline the customer experience. The goal was to have more of a self-service model, that was also far more timely in terms of order processing, clearing and settlement.

The design team went ahead and scoped the front end first, because they thought that this was most important from a customer perspective (and it was also a shiny and highly visible new toy!). However, when I heard about this focus on the front end, I was prompted to ask, “What will the customer experience be like?” By automating the process from a front end perspective, the proposed design would significantly diminish the need for customer interaction with relationship managers, and it meant they would have less direct contact with the bank. Whereas, part of the bank’s goal was to enhance the value of the customer relationship, especially their priority clients.

Also, by starting with the front-end first, the design did not take into account the actual mechanics and logistics of the middle and back office operations, so there were inevitable disconnects and gaps in the hand-off processes at each stage of the transaction. (This is a common mistake – a colleague who consults in the retail sector told me about the online storefront for a major retail chain that looked really pretty, but revealed no understanding of the established supply chain logistics and back-office order fulfilment processes.)

The bank team had a rethink of the storyboarding and workflow analysis, to make sure that the customer experience was streamlined, but that there were still adequate opportunities for customer touch points between client and relationship manager along the way.

2. Construction industry – inside and looking inwards

Another colleague told me of a specialist supplier in the construction industry, that was undertaking a review of their processes and service design model. From an internal perspective, everything looked fine. The customer orders came in, they went into production, and were then delivered according to the manufacturing schedule.

However, there were two stages in the process, that did not work so well from a customer perspective:

First, customers did not receive any confirmation or acknowledgment that the order had been submitted; so they might be worried that their order had not been received.

Second, once the order had gone into production, there was no further customer communication until it was ready to be delivered. Meanwhile, the client’s own schedule might have slipped, so they might not be ready to take delivery (we’ve all seen those moments on “Grand Designs”). Resulting in the supplier having to hold unpaid for work-in-progress in their warehouse.

For the supplier, it was a simple case of implementing a formal acknowledgment process, and a check in with the client prior to fabrication and a follow-up prior to delivery to make sure schedules were aligned.

3. Energy sector – gaining empathy in the field

A friend of mine ran a local distribution and installation business for an international supplier of energy switching gear. They specialised in remote operating systems, most notably used in indigenous communities. Head office was in Europe, and the clients were in outback Australia – so communications could be challenging. The overseas engineers would not always appreciate how time critical or simply inconvenient power outages or interruptions could be. “We’ll fix the software bugs in the next upgrade,” was usually the response.

Then the local business started inviting their European colleagues to come and work in the field, to get some downstream experience of how customers use their products. It was also a good opportunity to train technical staff on how to handle customers.

One time, a visiting engineer was in a remote community, trying to fix a power operating system. When Europe said they would take care of it in the next upgrade, the engineer pointed out that he was with the client there and then, and that without power, the community could not function properly, and that Head Office had to solve the problem immediately, even if it meant working overnight. The issue was sorted right away.

If nothing else, the visiting engineer, schooled in siloed processes and internal systems at Head Office, had managed to gain empathy from working directly in the field.*

While none of these examples seems to involve cutting edge design thinking, they do reveal some fundamental service design and product development concepts: the need for empathy, the value of prototyping and testing, the role of user scenario and workflow analysis, and the importance of challenging existing processes, even if they seem to be working fine on the inside.

*Footnote: This reminds me of a time many years ago when I was travelling around Beijing in the back of a cab, between client visits, calling my production team in the US, asking them to investigate a problem the local customers were having in accessing our subscriber website. “The Chinese government must be blocking the site”, I was told. Given that most of the clients were state-owned enterprises, or government departments, I thought this was unlikely. Turns out that the IT team in the States had “upgraded” the SSL without informing anyone and without doing multiple site testing first. Some clients had problems logging on from slower internet services, because the connections timed out. Being in the field, and speaking directly after witnessing the client experience for myself enabled me to convince my colleagues of what the cause actually was. Although we had to implement an interim workaround, going forward, every software upgrade or product modification was benchmarked against multiple test sites.

Next week: More on #FinTech, #Bitcoin and #Blockchain in Melbourne

Change Management for Successful Product Development

Recently, there have been a number of commentaries on the current trend/fad for applying Agile and Lean product development methodologies to corporate management. I’ve also noticed an increasing focus on “Product Management” as a formal discipline by training and professional development providers. Consequently, I’ve been revisiting some work I did many years as part of a Change Management Diploma.

Situational Leadership

My thesis is that different Change Theories of Management can be applied to each stage in the Product Development Cycle*, to ensure that the organisation is aligned with the business needs as they relate to strategy, capabilities, capacity and execution. This is also the context in which organisations use Situational Leadership techniques to cope with constant change in technological, social, economic and environmental forces.

(*This work was based on a reading of Theories of Organisational Change as Models for Intervention by Dunphy & Griffiths (published by Australian Graduate School of Management – Centre for Corporate Change, University of New South Wales, 1994). For a copy of my model, please contact me: rory_manchee@yahoo.com.au)

1. Fit for Purpose

Various skill sets are needed along the journey from ideation to production, and management has to harness appropriate resources to increase the potential for success. Organisations may need to consider restructuring to maximise their ability to develop sustainable product development systems that incorporate continuous improvement, feedback loops and market responsiveness.

For example, moving from annual software updates to quarterly releases might simply suggest some production rescheduling, but it may also mean changes to documenting user requirements, customer billing systems and client support tools.

2. Playing to Our Strengths

The person who is great at capturing the design specs may not be the best person to undertake market testing with beta users. And it’s generally accepted that someone who is adept at working in a production or QA role on an established product may need some re-training before they get to work on building a prototype.

3. The Model Approach

In conclusion, my analysis reveals that at each stage in the Product Development Cycle, there is a need to review the relevant Business Challenges, address the corresponding Change Issues, and apply appropriate Change Management models or techniques.

 

Update on Perspective – Introducing the “We R One World  Game”

In a recent post on “Perspective”, I commented on the value of stepping back and taking a different look at current ways of doing things. For an immersive, interactive and experiential learning opportunity on how to gain a new perspective on problem solving and how we might address global challenges, the Slow School of Business is running the “We R One World Game” on Saturday, July 25 in Melbourne

Dymaxion_map_ocean2

The Dymaxion or Fuller projection is a world map, which can be rendered in 2-D.

Facilitated by Ron Laurie, and based on the pioneering work of Buckminster Fuller, this event promises to combine a hackathon, a meetup and an unconference all in one! Tickets available here.

Next week: Who needs banks?

The 3L’s that kill #data projects

The typical data project starts with the BA or systems architect asking: “fast, cheap or good – which one do you want?” But in my experience, no matter how much time you have, or how much money you are willing to throw at it, or what features you are willing to sacrifice, many initiatives are doomed to fail before you even start because of inherent obstacles – what I like to refer to as the 3L’s of data projects.

Image taken from "Computers at Work" © 1969 The Hamlyn Publishing Group

Image taken from “Computers at Work” © 1969 The Hamlyn Publishing Group

Reflecting on work I have been doing with various clients over the past few years, it seems to me that despite their commitment to invest in system upgrades, migrate their content to new delivery platforms and automate their data processing, they often come unstuck due to fundamental flaws in their existing operations:

Legacy

This is the most common challenge – overhauling legacy IT systems or outmoded data sets. Often, the incumbent system is still working fine (provided someone remembers how it was built, configured or programmed), and the data in and of itself is perfectly good (as long as it can be kept up-to-date). But the old applications won’t talk to the new ones (or even each other), or the data format is not suited to new business needs or customer requirements.

Legacy systems require the most time and money to replace or upgrade. A colleague who works in financial services was recently bemoaning the costs being quoted to rewrite part of a legacy application – it seemed an astronomical amount of money to write a single line of code…

As painful as it seems, there may be little alternative but to salvage what data you can, decommission the software and throw it out along with the old mainframe it was running on!

Latency

Many data projects (especially in financial services) focus on reducing systems latency to enhance high-frequency and algorithmic securities trading, data streaming, real-time content delivery, complex search and retrieval, and multiple simultaneous user logins. From a machine-to-machine data handover and transaction perspective, such projects can deliver spectacular results – with the goal being end-to-end straight through processing in real-time.

However, what often gets overlooked is the level of human intervention – from collecting, normalizing and entering the data, to the double- and triple-handling to transform, convert and manipulate individual records before the content goes into production. For example, when you contact a telco, utility or other service provider to update your account details, have you ever wondered why they tell you it will take several working days for these changes to take effect? Invariably, the system that captures your information in “real-time” needs to wait for someone to run an overnight batch upload or someone else to convert the data to the appropriate format or yet another person to run a verification check BEFORE the new information can be entered into the central database or repository.

Latency caused by inefficient data processing not only costs time, it can also introduce data errors caused by multiple handling. Better to reduce the number of hand-off stages, and focus on improving data quality via batch sampling, error rate reduction and “capture once, use many” workflows.

Which leads me the third element of the troika – data governance (or the lack thereof).

Laissez-faire

In an ideal world, organisations would have an overarching data governance model, which embraces formal management and operational functions including: data acquisition, capture, processing, maintenance and stewardship.

However, we often see that the lack of a common data governance model (or worse, a laissez-faire attitude that allows individual departments to do their own thing) means there is little co-operation between functions, additional costs arising from multiple handling and higher error rates, plus inefficiencies in getting the data to where it needs to be within the shortest time possible and within acceptable transaction costs.

Some examples of where even a simple data capture model would help include:

  • standardising data entry rules for basic information like names and addresses, telephone numbers and postal codes
  • consistent formatting for dates, prices, measurements and product codes
  • clear data structures for parent/child/sibling relationships and related parties
  • coherent tagging and taxonomies for field types, values and other attributes
  • streamlining processes for new record verification and de-duplication

From experience, autonomous business units often work against the idea of a common data model because of the way departmental IT budgets are handled (including the P&L treatment of and ROI assumptions used for managing data costs), or because every team thinks they have unique and special data needs which only they can address, or because of a misplaced sense of “ownership” over enterprise data (notwithstanding compliance firewalls and other regulatory requirements necessitating some data separation).

Conclusion

One way to think about major data projects (systems upgrades, database migration, data automation) is to approach it rather like a house renovation or extension: if the existing foundations are inadequate, or if the old infrastructure (pipes, wiring, drains, etc.) is antiquated, what would your architect or builder recommend (and how much would they quote) if you said you simply wanted to incorporate what was already there into the new project? Would your budget accommodate a major retrofit or complex re-build? And would you expect to live in the property while the work is being carried out?

Next week: AngelCube15 – has your #startup got what it takes?