In a recent conversation with an entrepreneurship professor here at HBS, we got into a discussion about how business school students often lack the operational and technical skills needed to be a successful founder.
He asked for my thoughts on the 20 operational skills I thought were most useful to a founder and I came up with the list below, in no particular order. (Note – this is specifically for tech startups)
- Statistics and analytical skills – you don’t need to be a data scientist, but knowing how to interpret which business-critical data, and ask the right questions about it, is essential.
- HTML / CSS – you don’t need to be a developer but you need to understand the basics of how to do things like embed an email form, update text, design an email, etc.
- Understand how databases work – if you understand the fact that the boxes you put your data in can impact functionality in the future, you can have more productive discussions about these potential challenges.
- Project management skills – can you break down a project into a number of small steps, prioritize them and organize the people working on them?
- How digital advertising platforms work (like AdWords, Facebook Ads, etc)– not just the functionality but the concepts behind CPM vs CPC, bidding strategies and reporting
- CRM systems – If your customer database is a Mailchimp list, you probably need to look into a CRM, both for leads and for existing customers.
- SEM – search engines are still a major traffic driver for many businesses. Have a good idea of how they work.
- Networking – and even more importantly, maintaining a network so you have people to call upon for hiring, fundraising and support.
- Financial literacy – in particular an understanding of how cash flows work
- Know how to read a term sheet – If you’re going to be fundraising you should probably have a good idea of what you’re signing before your sign it.
- Version control systems (i.e. git) – You may not be a command-line genius but you should know the basic lingo and understand why version control is so important for your developers and your product.
- Empathy for developers – you don’t *have* to be able to code, but you should have a deep and honest understanding of the problems engineers have to solve, what is challenging for them, their priorities, etc.
- Know where to go for help – if you haven’t heard of Stack Overflow, you’re probably not looking up enough answers for yourself. Beyond technical guides, there are industry-leading blogs on marketing, fundraising or growth hacking, forums and subreddits for entrepreneurs and pretty much endless resources on and offline.
- Eye for design/usability – at the very least you should have someone you trust in this department. It’s not worth having a product fail because the concept was great but no one knew how to use it. This also goes for user tests, focus groups and surveys – usability is key.
- Understand and use feedback channels – whether you’re using an online service, running a focus group or picking up the phone, you need to be able and comfortable getting and interpreting feedback.
- Hiring – recruiting, interviewing and managing new hires as well as experience working with many different types of people will make those first 10 hires more effective.
- Content marketing, and scalable ways to do it – Content marketing, including email, social media, blogs and custom landing pages, can be a critical but time consuming growth channel. Understanding marketing automation tools can save a lot of time and effort.
- How to set up and read analytics platforms – At a minimum, you should be Google Analytics-literate, but understanding other analytics options (such as Kissmetrics, Mixpanel, Flurry, etc) is useful if you feel you’re not getting the answers you need.
- Pitching / the perfect elevator pitch – you should be able to communicate what you are doing, who you are doing it for and why they care in 30 seconds and make it sound convincing. If it takes you over 2 minutes to explain the concept, you may be in trouble.
- How to give and receive feedback – while it’s easy to ask for feedback, it’s not always as easy to listen to it. Practice accepting (and delivering!) the more critical comments as well as the more positive ones.
In general, I think a founder could be summed up as a schizophrenic masochist – someone with a conflictingly broad range of skills who is constantly looking for ways they could fail with an unending belief that they will succeed.
There are of course any number of exceptions to the skills I’ve suggested – what would you add or remove from my list?
The other day I had lunch with Sarah from Unruly Media. We had a great conversation about agile methodologies, in particular agile in marketing. She certainly knows her stuff around agile – her company (of which she is a co-founder) started out in a very different place from where it is today but as the whole company was founded on agile principles, they pivoted to becoming a 100 person company across multiple countries selling a social and viral video enablement software to media agencies and their clients.
Sarah asked a really interesting question that I thought gets to the heart of why marketing should be agile. She wondered, if we already have plans for marketing, in a way we don’t necessarily have for other departments, like number of events or case studies per quarter, why do we need to break marketing’s task down into smaller stories?
My personal answer to that question has to do with the agile idea of continually adding value through numerous small releases. A marketing department can easily spend the quarter working their butts off to produce one fantastic event, however there’s really only one point at which the team delivers business value to other departments or customers – the day of the event. What if agile allowed marketing departments to turn that single event into a series of releases that added value to the business?
By breaking larger tasks down into small stories, each with the aim of adding value to the business, a marketing department can do two things. First, they can see where they need to focus their time in the lead up to a big event (or whitepaper release or new website launch, any activity works here really) because they’ve defined their stories in a way that helps the team understand where they are adding business value. Secondly, they can use these smaller yet valuable “releases” within marketing to delight customers and other departments more regularly throughout the process.
Let’s take, for example, hosting an event for new and prospective customers. One could easily argue that this project is only fit for a waterfall style release (you work on everything until it’s all finished then release all at once) and there is no way to deliver value to the business from this project until the event actually happens.
But look at the assets produced for that one day – handouts, speaker bios, marketing materials, case studies, training documents, video footage, email comms to attendees and event promotion. Why shouldn’t a case study be released to the sales team as soon as it’s produced, delivering value to their sales process? Couldn’t speaker bios be turned into blog posts showing your company’s involvement in supporting individuals in the industry, delivering value to your readers? Post video footage on YouTube early, make marketing materials the content basis for your Tweets, allow sales or support to piggy back on email comms – and most importantly show your company and your team how marketing is continually adding value.
The upshot of this is that marketing gets the recognition for the ongoing work they are doing and the company gains the momentum that comes with having continual access to new marketing and sales materials throughout the quarter.
Do you agree? Why do you think marketing should even bother with being agile?
Before getting started with an Agile methodology for our marketing team, we had to make some decisions about how to prioritise our stories, sprints and workloads. The first step was to decide what was really important in terms of the actual marketing channels, the objectives for each channel and the metrics we cared about.
This led to the creation of our Marketing Priorities Venn (shown below). Three circles for our three primary areas of focus – content, inbound lead generation and research and CRM management.
Anything that didn’t fall into one of these circles or their overlapping areas was out – there would be no stories in our sprints that didn’t fit in our Marketing Venn. Although the Venn might seem quite all encompassing, it was an eye-opener to see what tasks we had undertaken in the past that didn’t fall under any of our key channels, often related to supporting other departments or doing unnecessary admin.
But it wasn’t enough just to know what we should be doing – we needed to have a clear picture of why we were doing it so that stories could support the overall objective of each channel and iteratively drive us towards reaching those goals. Therefore we added a second Marketing Venn to illustrate the objectives for each channel – allowing us to eliminate stories that matched a channel but didn’t support our key objectives.
Finally, we wanted a way to understand how well we were achieving our objectives and created a final layer to the Marketing Venn with a list of marketing metrics that were relevant to each channel. The metrics list we fully expected to change over time as we determined which metrics were most relevant in helping us recognise our objectives but as a first pass we wanted to be sure that there was a quantitative way to assess the success of our work.
I’ve found the Marketing Venns particularly useful in deciding what stories to write in our upcoming sprints – not only does a quick glance remind me of our priorities but it also helps to ensure we have an even balance of work across all parts of the business for which we as marketing are responsible.
This is Part II of Challenges in Setting Up an Agile Marketing Team. Part I is available here.
Challenge: Measuring and assigning points to marketing stories
Agile is a great method for quantitatively measuring productivity because each story is assigned a point value. The sum of points from all stories completed during a sprint defines the team’s velocity. This velocity should be fairly consistent week on week and any sprint plans for the future shouldn’t include stories with a point value higher than the current velocity. Within a development environment, when, generally speaking, product developments are all created within the same framework (a programming language) with varying levels of complexity, the point values are relatively easy to define – a more complex project, requiring a greater knowledge of the coding language, is worth more points.
On the marketing side, however, assigning point to stories has been a real challenge. There is no consistent measurement of complexity across the very different types of projects we undertake – for example is designing a lead flow process for lead nurturing more or less complex than generating a detailed report analysing dead leads over the last six months? And if we can’t consistently evaluate complexity, should we use time to indicate point value – so should a very simple, repetitive task that takes an entire afternoon be worth more points than a task that only takes half an hour but requires a significant level of expertise? Should points indicate seniority – tasks that require executive sign off getting a higher value than those that do not?
Where We Are Now:
This particular issue hasn’t entirely been resolved. We’ve tried a number of different ways of measuring the point value of tasks but have resorted to ‘gut feel.’ We assign points as a team, during our sprint plan, so there is a check and balance but it’s not a particularly scientific process. This has been reflected in a somewhat inconsistent velocity – although we’re in the same ballpark week on week, our velocity doesn’t have the fixed value we’d like to see. Generally points are based on a combination of the perceived complexity of the task, the amount of time it will take and whether or not other resources are required from outside our department. Hopefully this process will become clearer.
As a side point, we used the same point values as our development team – 1, 2 or 3 points as the only options. Given the different variables we need to take into account and the inconsistency of measurement, we might find it easier to get a lock on our velocity with another scoring system.
A couple of other challenges that we considered before starting with Agile:
– Abundance of ‘chores.’
Chores are stories that don’t deliver any real value but must be completed. Some examples are following up with the winner of a competition, cleaning email lists or unfollowing irrelevant accounts on Twitter. Chores in our sprint plan give the appearance of productivity without any value-add to the department, and makes it more difficult to accurately measure our velocity (chores don’t get any points). We tend to have a lot of these within marketing and are working to tie these in as tasks related to proper stories, rather than just stand alone stories without value.
– Lack of resources and skills for partner work
Many Agile teams recommend having paired teams of workers complete stories together. While our challenge is based more on the siloed skills sets within our team, our small team size and general need for speed has deterred partner pairing as well. However, we’re lucky enough to have some fantastic interns working on the marketing team and although they are not generally part of the sprint plans or responsible for stories, their support helps us recognise some of the value of pair work.
– Reliance on other company departments
Within the development team, much of their work is self-contained however in many cases, our marketing team requires support from other departments to complete a story – whether that’s a product release from dev or testimonials from support. Reliance on other departments makes planning stories incredibly difficult because if we don’t get what we need from the other parts of the company, the story can’t be completed. We haven’t found a great solution for this one yet, although we have tried to write fewer stories that require outside resources and if one is required, create a chore to request the resource, then a story only once we’ve received what we need.
So, as you can tell, numerous challenges although it’s been an important process to think about these because they affect the team’s output regardless of the methodology we’re using. Agile has helped to highlight some of the ways we can improve and given us a framework for doing so.
Next post will be about how we prioritise work, define projects and write stories.