! JavaScript disabled. For an optimal Spowtr experience, adjust your browser's JavaScript settings.

Spowtr — Agency to platform: Using Agile values and principles to make it happen in less than a year. by LorenzoPrinci
Chevron icon pointing left
Home
Agency to platform: Using Agile values and principles to make it happen in less than a year. By Lorenzo Princi

Agency to platform: Using Agile values and principles to make it happen in less than a year.

Lorenzo Princi's avatar
Lorenzo Princi aka LorenzoPrinci 2014-11-17 14:59:02 m read
Share icon

I recently presented at Agile Tour Sydney (see a snippet below) on how Elastic Grid (where I am the UX Lead), transitioned from being agency to a product, and how the four values of Agile helped this challenging process.

Who we are and what do we do now

Elastic Grid is a B2B marketing platform which enables vendors (manufacturers or suppliers) to reach end-customers via their partner (or re-seller) community. This is done by hosting complex Multi-Touch co-brand-able Lead Nurture Campaigns that Partner Sales & Marketing teams can leverage to target their customers easily and effectively.

What we were and did before

Elastic Digital, as we were previously known, was split into multiple single skilled teams; producers, designers, front-end and back-end developers focused on delivering digital campaigns and other creative solutions to our clients. Though the solutions were predominately around demand generation and sales enablement, not all were hosted on the previous version of our platform, as many were stand alone concepts.

Basically, we would (as an agency does) do anything requested by our clients and I remember joking that we were selling ourselves like a local print shop. A design for a mouse pad was the furthest we strayed from our core offering...

What was apparent, was the lack of ownership of the deliverable solutions and extreme Waterfall nature of our processes. There were times I was updating a few words of text on a design so that it could be reviewed again by the client for final sign-off, only to then have it returned with feedback about something else entirely. That feedback, in-turn would often end up on another designer's plate because I had already been scheduled to work on updating another design, which I didn't work on in the first place. I would have no context of what it was or what it was meant to do. It was confusing and frustrating.

The Grid platform as it was known at the time, was only a part of our business and far and away the most effective in generating a return on investment for our clients and their partners. That being said, we were focusing heavily on creative digital projects for immediate revenue with less investment and focus on the platform itself.

It came as no surprise when we did a fact finding mission with our clients, who when asked, "What does Elastic Digital do?" Responded with a multitude of there-about words regarding digital marketing but no concrete statement as to what we fundamentally did to help their channel marketing efforts.

Here's me showing a speech bubble of random digital marketing nouns:

This came about through many layers of different processes blending together. Essentially, while trying to be an agency, we were at the mercy of our clients and we simply did what they wanted because, "It's what they want". The only factor in whether we should take on a project was not whether it fit our business model but rather whether or not we had the skills and tools to do it.

This is a dangerous road and as mentioned earlier, we technically could design a mouse pad for a client, but that didn't mean we should have used our resources to do so. For example, I've no doubt the people at Twitter can build a website for you, but I doubt they will if you ask. 

We were stuck in a vicious cycle focused on meeting monthly budgets which led to all sorts of disjointed projects being taken on.

The metric for success became, "is this signed-off?"

Individually, we just wanted to get the piece of work off of our plate and onto someone else's. This was terrible for culture and personally found relationships being strained as a result. Not to mention job satisfaction.

As a business, the worst part of it was the amount of waste. We were solving the same problems over and over again, just a few pixel different depending on the client.

How Agile helped

The first Agile value we needed to adopt was "Responding to change over following a plan". This was crucial to re-laying the foundations of the business. We had a plan to be a B2B agency and develop bespoke campaigns for our clients that their partners could leverage. However, due to changes in the market around the expected speed to market for a digital campaign and more and more requests to enhance platform functionality, we knew we would have to respond to these changes.

We therefore allocated more resources to the platform, which at the time only had a team of back-end developers. We introduced user experience, business analysis and quality assurance to ensure usability, priority and stability know that we were considering increasingly complex features.

In turn, we simplified our campaign creative process by creating ready-to-go customizable templates (or blueprints as we call them) which enabled our creatives services team to get complex lead nurture campaigns onto the platform quickly. We also nullified the amount of time spent on non-platform or standalone creative work. Despite internal fears about how our clients would respond, the fast-to-market option proved so popular that it is pretty much covering all campaigns.

New market position

We also addressed our external positioning problem, facilitated by our good friend Ivan Gavran from AltusQ, an off-site session lead us to redefine our offering and was critical to being able to re-position ourselves. The first stage was to go back to basics and re-discover what the company had initially stood for, as explained on our company story page:

"More than a decade ago, in Sydney, Australia, our CEO and Founder, Cameron, observed that beers, rugby, golf, and print ads (pretty much in that order), were the typical IT product marketing manager\'s list of things to do.

The return on investment? Not quite measurable...

Yes, some great relationship-building went on. We\'re talking about beer here, after all. But were deals done and revenue raised? Were they all attributable to those activities? Possibly, but how could it be measured? Which activities did, or did not, generate leads and convert those leads into revenue?

Suspecting some significant wastage of marketing funds, our founder created Elastic Digital. The quest began: Create measurable ROI for the B2B IT channel, globally."

Essentially, at our core, we exist to help vendors reach customers via partners. Therefore the real key to create success was to focus on the common element in the chain, the partners. These were our actual users, if we made life easy for them and got them the results they were after from their marketing efforts, our clients, the vendors would be happy. This subtle shift in our mindset changed everything.

Redefine the metrics

Taking the above, we could now, rather than have a black and white, "will someone pay us to do this?" mentality. We are now able to ask primarily, how does this fit into our goal of:

Self-managed, scalable, demand generation and enablement tools for channel marketers and their partners.

We now always go back to, "Is this going to get results?" In that context to make decision making a little bit easier and pull ourselves of the content and back up into the context which is a trap easily fallen into.

A re-brand!

Once our new offering was defined, we could also re-brand. Since it was clear that our platform, The Grid, had a significant place in the hearts and minds of our larger clients, with the name being known around channel marketing circles in Silicon Valley, coupled with the fact that out clients and peers were not relating to Elastic Digital, we decided to re-brand ourselves as Elastic Grid. Dropping "digital" was significant as a move away from agency, as it very much had an agency ring to it.

I developed a logo which evolved from the companies original, still keeping it's fundamental concept of elasticity and agility.

Becoming user-centred

The great fallacy in our old approach to the platforms architecture was that vendors had exclusivity to their partners. This lead to one "Grid" per vendor. What was affectionately known as Grid 2.0 was rolled out individually for each of our clients to host their individual campaigns on and their partners would log in, find those campaigns and run them.

However, in reality, partners would provide their customers with solutions and products from more than one vendor. In the I.T. industry specifically, when you think about storage, security, networking, etc, a partner would have to access multiple "Grids" to effectively run their marketing initiatives.

This approached caused two major challengers:

  • Firstly, the clients' owned their "Grids", meaning we had all sorts of customization for each vendor which had piled up over the year. Mainly around branding and other non-essentials as far as partner use cases went.
  • Secondly, the usability was poor and when trying to fit new features into existing workflows for ease-of-use, it felt bolted on rather than seamless. We also had to work around some legacy "IF VENDOR_X" show this message type stuff which only "so and so" knows about. This would therefore cause user experience exceptions being added to some of the Grids.

We knew this had to change technically if we wanted to improve usability and scalability but also as far as a mentality which we needed our clients to understand. The only way forward was to take a user-centred approach.

The high-level platform architecture looks something like this now: 

Elastic Grid exists in the cloud and is actually a group of separate applications (seamless to the user) that handle their own part of the puzzle. Like so;

  • Portals are essential shop fronts for vendors so that they can showcase their tools and services to their partners and act as an entry point.
  • The Campaign Launcher is the main user control center for managing their contacts and campaigns and is completely free of any specific vendor branding.
  • Analytics is used for viewing reports and tracking campaign performance.
  • Accounts is where users manage their personal and company settings. All of this is accessed via a single sign-on and the tool is fully responsive so that it can be used on any device. Only the vendor portals offer any sort of branding customisation, however this isn't bespoke per vendor; we offer the same do-it-yourself customisation to all our clients.

This architecture allows us to rapidly improve and add features to the suite of applications because we aren't managing multiple versions. By stressing the fact that we are in constant discussion with partners and actioning feedback to resolve pain points we have been able to steer the conversation away from vendor "wants" and focus on their actual needs.

Working software over comprehensive documentation?

We flipped this value on it's head a little bit by taking Agile beyond the software. Where Agile used to mean; "The back-end developers do daily stand-ups", Agile is now a philosophy we apply to the entire business.

Collectively we:

  • Talk to users (at all levels of the business)
  • Collect feedback
  • Analyse feedback and requests
  • Build small features
  • Test them
  • Repeat

Customer collaboration over contract negotiation

One mantra we have is to always solve core problems and really get to the bottom of the needs of the stakeholder/user, etc. “What are you trying to achieve?” is a question I often find myself asking when presented with the next feature request, often spelt out exactly how it needs to look and work.

One example I point to is how we solved the problem of certain partners not being legally allowed to run certain campaigns in their regions.

What we were asked to deliver:

  • User tries to launch a campaign
  • User is told the campaign required approval
  • Email goes to an administrator (we don’t know who yet)
  • Administrator gets a spreadsheet out and checks (manually)
  • Administrator approves or denies
  • User gets an email saying they can or can’t now run the campaign.

After asking the right questions and getting to the bottom of what the core requirement was, we understood that what was needed was to ensure partners in certain marketing regions were not able to run certain campaigns due to legalities. Knowing the problem, we came up with following automated solution which required no approval workflow at all.

What we actually delivered:

  • User logs in
  • The system already knows what region they are in
  • We start tagging campaign modules to regions
  • Campaign indexes don’t show campaigns they can’t run in their region
  • Direct links to a campaign detail screen shows a sorry message instead of our launch campaign CTA.

The difference between the two, for users, was that those who would be approved were no longer going to be delayed by the manual workflow and those who weren't going to be approved, would never know and be presented with that negative experience. We also eliminated the need for a manual approval process which didn't seem like it would be much fun for whoever that was assigned to. Empathy now plays a very important part of our solution orientated thinking.

Technically the difference was also very important, as we didn’t have to implement and test a complex work-flow with a heap of checks and flags for who can and can’t run certain campaigns. This isn't to say we couldn't technically do it, that just isn't our approach any more.

This is only a simple example to illustrate the mentality we use for everything we do.

Individuals and interactions over processes and tools

As stated above, the team structures were once based on profession, I was in the "design team", there was a team of producers, we had a team of front-end and back-end developers. The idea being, "these people need to talk to each other" but the reality was we all felt very isolated. We were assigned tasks to do and then sent them off into the void only ever hearing back about them if there was a problem. We had a quite office with a very negative culture. Barely a water cooler conversation was to be heard.

Using some techniques facilitated by our leadership coach Ivan which aligned very well with the Agile principles around creating small cross-functional teams. We were able to re-shape and re-layout the office to better suit the needs of creative people.

We now have a creative services team which works on campaigns with a process that involves collaboration between copywriters, designers, developers and producers along with the client. The campaigns themselves, though far simpler than the days of doing bespoke and never-ending projects, is turning out much more interesting and successful campaigns than ever before.

Our product team is a more traditional SCRUM team focused on delivering iterations of features, bug fixes, and improvements every 2 weeks for the platform. We have user experience (that's me), quality assurance, front and back end developers, development operations and a business analyst who all work together to solve problems and deliver each iteration.

The two teams don't keep to themselves either though, we now have a heavy focus on "Engagement", encouraging people to really understand what the task they are doing is all about and how it fits into the greater business context.

The final thing is now that teams a responsible for what they are producing and the blame game which came with the pass-the-buck modal no longer exists. For instance, our sprint retrospectives are run with an "acknowledgement" focus to avoid judgement creeping in when discussing what didn't go so well.

Personally, the thing that makes me the happiest is seeing things like this going on it the office for real and not having to stage it for a photo:

The outcome

We are far from done and we are far from perfect. However this story is meant to highlight that using Agile values can help to re-focus an entire business and not just a software development project and lead the way to bigger and better things. We have much still to do and are constantly refining and revising our processes but we've come a long way. We still need to train all our staff on how having an Agile mentality applies to their specific role within the company.

The most important thing for anyone making these sorts of fundamental changes is conviction. There will be hurdles and you can\'t give up at the first sign of trouble. There will be fear and trepidation and lots of discussion. What we can see now is that overall, the business is filled with happier, more productive and motivated staff and has seen an increase in revenue as well as a client base. Most important of all however, we have taken ownership of our offering.

Takeaways

You may not be trying to transition or pivot your company but you should still keep the following in mind.

Know your core offering: You may have a heap of things you can do to help your clients, but make sure you have an underlying reason for being that isn't a bunch of nouns. Examples include, Campaign Monitor who state "Send Beautiful Emails" or Drop Box whose core offering is, "Your stuff, anywhere".

Be aware of your culture: Just because ow one complains doesn't mean everything is going great. Ask a few questions, look around and get an idea if people are really engaged in the work they are doing.

Leverage your problem solvers: Are you dictating how solutions should be implemented? Generally, you hire talented designers, developers and other creative thinkers to solve problems. Let them work how they want to work and let them self-organise.

They'll surprise and delight!

Conversation icon 0 Responses

Community sentiment

Strong agreement

Two thumbs up icon

Do you agree?

Login to add sentiment

Write a response

Take some time.
Collect your thoughts.
Login or join to respond.