Simplify. Work out the kinks. Re-focus.

That’s our plan for 2012, discussed in meticulous detail over the past couple weeks during Magnus’s visit to Cape Town. Exactly what that entails remains top secret for now. What we hope will increase happiness levels amongst our users is our quest to make our support structures more efficient. Working out the kinks.

With 123 themes and 123 theme docs, and other support resources including a knowledgebase, FAQs, a support forum, tutorials and a video library catering for over 130,000 users it’s very much a daunting work in progress that we are tackling one resource at a time. Below details some of the work going on behind the scenes recently.

Talking 2012 strategy with our latest board member - Adii Junior.

Email

Mid last year we implemented Assistly, a customer service system, to manage our pre-sales and administration email. Previously, we simply used Google Mail and thanks to IMAP between myself, Adii and Ryan we managed to keep the mailbox under control and synchronised. We still use Google Apps to deliver our mail, but thanks to Assistly we now have a sexy, fast interface to use, we can assign mail easier, track response times and draw all sorts of interesting reports on customer interactions, resolve email threads, as well as manage our social media channels, like Twitter, without worrying about numerous staff members replying to the same tweets. There are a wealth of other facilities we are yet to tap into, but hope to explore soon.

Capacity wise we now have Ryan in the United States, Sven in China, and Adii overseeing the inbox here in South Africa – covering all time zones helping us deal with the 150+ emails we receive and keep our response times impressively fast, averaging under 3 hours.

Reports gathered thanks to Assistly.

Support Forums

With the launch of our own custom membership system late last year we re-developed our forums. In the short term that meant lots of small bugs and hassles as we took the database structure of bbPress, stripped the unnecessary code and built on top of it. In the longer term it is now meaning we have far more flexibility in terms of how our forum threads are presented, managed, answered and assigned.

The team can now assign topics

Previously we used Lighthouse to track bugs/feature requests and assign to our developers/designers, but that meant logging into another system and no direct automated correlation between a user reported issue and it’s fix. We now have the assignment of threads and conversion into bug reports automated within our forums.

We also have various admin views for quick access to support threads that need attention, and a ninja leaderboard to help encourage the team when they aren’t performing as well as the rest of the team know they are capable of, so we  can pat team members on the back and reward them when they are doing well, and keep track of their targets they have to meet each month.

Useful forum tools and stats available for the team.

We’ve also implemented strict controls on who can post on a user’s thread – only the support ninjas and the user who started the topic. This may seem impractical to some, reporting the same query again, but it helps us keep track of what is resolved, with only the original poster able to open the thread again. Having a closed forum also avoid answers that might be wrong or off topic from other members, which in return ensures that we can deliver proper support from our WooNinjas.

Only topic author can reply to a topic.

A user also needs to wait for a support ninja to reply before they can comment on a thread again. They can of course edit their post, but by limiting further replies allows the support queue to stay in order. Our ninjas try to reply to the oldest posts first and as soon as a follow up post is added to the mix it goes to the back of the queue again = unhappy customer.

After posting, members are asked to wait to avoid bumping threads.

These revisions may sound rather minor, but they’ve had significant results on support levels. We are still struggling with overwhelming numbers of support queries at the moment, but have hired a new support ninja we hope to introduce soon, as well as headhunting a more senior support manager which we have no doubt will help increase capacity and customer happiness levels even further.

Videos

Some of the WP101 titles available to all our users in the support section of the site.

Video tutorials are an important part of our support resources, a more visual learning experience. We’ve recently updated our video library with our good friend Shawn Hesketh’s latest WordPress101 series that can be used by our users to train their clients, or even themselves. The WordPress101 series is geared for WordPress 3.3 so is up-to-date and hugely helpful in getting to know the WordPress system.

And there you have it, a small glimpse into the recent behind the scenes happenings at WooHQ in trying to ensure happy customers, and the often hard graft that entails.

Back to the current day…

A couple of weeks ago, we were made aware of serious security flaws & vulnerabilities in the TimThumb script (by a 3rd-party developer), which we use to dynamically resize user images in our themes. We reacted immediately by updating & securing all of our themes and making these new versions available to our users. In our mind, we had taken due action, and based on the minimal bad reports we had from our users, this didn’t seem to be a widespread problem.

Things went relatively quiet for the few days after the blog post and we were helping out a small handful of our users that had been adversely affected by the security flaws. But then we started noticing that more & more users were complaining of an issue and two weeks after the initial blog post, we released further updates to our themes (to make it easy to spot & fix the vulnerabilities easily), as well as sending out an e-mail newsletter to all of our users, advising them that the issues were indeed critical and that it required urgent & decisive action on their part to resolve this.

Unfortunately this was too late for some of our users, who had already had their sites compromised as a result of the vulnerabilities. This is what we’ve learnt from this experience:

1. Don’t underestimate the situation. We underestimated this situation and the significance of the vulnerabilities initially. We didn’t want to create widespread panic amongst our users and as a result we took what we thought was sufficient action by releasing the updated versions and blogging about it. The situation and potential issues were however much bigger than this at the time and whilst we didn’t release it, we should’ve pressed the panic button and created the appropriate sense of urgency to get our users to fix their sites.
2. Go to e-mail immediately. We blogged & tweeted the issues, since we have a lot of traction with our users on both these channels. In hindsight though, we also know that not all of our users follow us on these channels, whereas we know we’ve got the e-mail addresses of all of our users. We should’ve gone to e-mail immediately, because even though we only have an average (approximately) 40% open rate on e-mail newsletter, this is still the best way to get in touch with the biggest majority of our users.
3. Communicate over & over. We should’ve possibly sent out multiple e-mails and also blogged & tweeted more. We should’ve done everything imaginable to try reach every one of our 40 000+ users. We should’ve been more gung ho in pursuing that goal.
4. Use “panic words”. We should not have worried about scaring our users and we should’ve probably create a state of panic. This is of course an overly cautious approach, since many users weren’t affected, yet with this approach we would’ve scared them as well. Some users might’ve been pissed off because we falsely scared them, but this is a “better” outcome than having to say sorry to users for having their websites compromised.
5. Actions speak louder than words. Saying sorry in a situation like this goes a long way and we tried to do this very often in communicating with users during this issue. Sorry however isn’t enough and needs to be backed up with action; taking action in terms of addressing users’ concerns and getting their sites fixed. ASAP.

We know that we didn’t act ideally and we definitely know that we could’ve done much better. We also know that we had no experience of managing a crisis situation like this before and that the only way we can grow as a company is to learn from experiences such as this.

To our users… We’re really sorry about not being awesome in the way we handled this situation. We’re even more sorry to those of you, who had their sites compromised. We live & we learn. And we will be doing better in the future. If there’s anything that sets us apart as a team & a company, it is the fact that it is our ambition to grow & improve every single day. We’ve come a long way thus far and experiences such as this will only make us stronger.

Before I share the details of these concepts, I need to provide some context. Basically when we started WooThemes 3+ years ago, Mark, Magnus & I did so without any type of “best practice” programming background, which meant that we were simply doing whatever us novice programmers thought yielded the best result. As we’ve grown up, those initial days and workflows have become part of our core processes and routines, which made us a very well-oiled machine.

As time has gone on though, and as the team has grown, we’ve realized that whilst our existing workflow obviously isn’t broken, it could definitely do with some improvements. Improvements in turn means increased efficiency & value for the WooCommunity.

So with that in mind, we’d like to share the two things that we’ve recently implemented that has already made a huge difference to how we work. Neither is groundbreaking or unique in its own right, but the benefits we’ve experienced already at least justifies a blog post.

Hackathons

We’re not big on deadlines & milestones, so our themes have very flexible development timelines – as long as we release two themes a month. What we found though is that the process to get a theme to 95% completed was easy & streamlined, but then the final 5% work – involving final feature inclusions, browser testing, demo setup, bug fixing – took much longer and generally forced us to rush to get it out the door. Rushing towards a deadline means we’re compromising on our time, and we’re probably also missing minor bugs that could’ve been avoided if we weren’t rushed.

Hackathons scheduled in our Basecamp calendar.

To improve on this, we’re now scheduling a hackathon as soon as we get the theme to 95% completion. A hackathon could be 6 hours, or 2 days and during this time the responsible WooTeam members focus all of their time & energy to wrap up the theme ready for release. No one is to bother the team members with other tasks during their hackathon, so there are no distractions which means that the last 5% is completed in a much smoother process.

A by-product of this has been that we’ve actually included additional functionality in both our recent releases (Statua & Editorial) due to the focused time that the guys could spend on both themes during their hack days. Double win.

Teams

A WordPress theme in itself isn’t really big enough to have the 7 developers and designers of the WooTeam working on it at once, because we’d inefficiently be stumbling over each other’s feet. So we’ve all been basically doing our own thing, working on our assigned theme tasks on the to-do lists. This workflow however sometimes results in certain projects not being wrapped up (efficiently or at all), since there’s no one that takes responsibility for the whole project from start to finish.

We are countering this with the use of internal teams. Basically this means that for every theme we create a mini-team, which generally consists of a project lead (who is responsibility for quality assurance & project management), a support ninja (who also does the basic WooFramework integration) and an advanced developer (currently either Matty or Jeff, with Warren to soon start helping out). Every mini-team therefore has the necessary skills to complete the project at hand.

What we’ve seen is that this brings an increased efficiency to our workflow, because the team can now take proper responsibility for their tasks and they can also keep each other accountable. Having 3 people actively working on the same project means a quicker project, and hopefully means we can start building up a backlog of themes to release, buying us more time to work on innovative features for the framework.

Team Comarty creating awesomeness!

Feedback from the guys has also indicated that they enjoy the fact that their little teams almost generate their own identity (Mark, Cobus & Matty recently worked together on Editorial & “branded” their team as Comarty), which results in a closer collaboration. Whilst this is seemingly simple and the idea for teams again isn’t unique, it’s not necessarily something that is so obvious in a small team like ours. Again though, the benefit has been massive.

Do you have any experience with either of these concepts or something similar? What do you do within your teams to boost efficiency & productivity?

I eventually settled for “To All Photographers: Meet Statua”, which is one of the ideas that didn’t seem too stupid or repulsed me.

The thing is that I know I could’ve done something simple. Maybe something like “Statua V1.0 Released”. That’s clear, concise and communicates what the post is about: we have released a new theme called Statua. Simple. It is however also boring as hell.

We don’t do boring. It’s never been one of our brand attributes to be boring and we’re definitely not gonna start being mundane with the headlines of our blog posts either. I regularly laugh at myself for the headlines that I end up using for blog posts, because there are some really silly one’s in there. But at least they’re not boring. And some of them are even quite quirky I’d think.

Boring isn’t wrong; it’s just not us. We could easily use headlines such as “Statua V1.0 Released”, but that would very quickly make the blog seem like a very formal, technical place for advanced developers. Instead our blog is one of the cornerstones of the WooCommunity and we want it to be a fun place, where we can have valuable, interesting interactions & conversations with our users. That’s what we’re about and our attempts at quirky headlines are much better suited to our audience and achieving these goals.

So quite a while back, we decided to implement this into our workflow in the WooHQ, as we were continually finding ourselves rushing to meet the deadlines that we set ourselves, which just caused a working environment that wasn’t much fun, due to that stress associated with meeting those deadlines. For quite some time, this has served us really well, since it most definitely eliminated the stress of those deadline rush days.

But recently we started noticing that this mentality also caused a few negatives to creep into our workflow…

Things were just not getting done as quickly as they used too. We had become so flexible in terms of meeting our milestones (which we set ourselves to be proactive), that we were spending more time adapting those milestones than actually accomplishing them.

Beyond the fact that our club subscriptions promises 2 new themes a month, we are an ambitious team and as a result we don’t want to take 3 months to release a new theme, when we could’ve done it in a week. Simple as that.

So we set about tweaking our currently workflow accordingly:

• Deadlines are back, but we’re flexible about adjusting those when it’s appropriate / valid / clever to do so. We’re not fixated on deadlines only and are flexible enough to prioritize other tasks too. We do however have a renewed commitment to try meet all of our milestones, thus giving us a balance and the best of both worlds.
• We’re upping our usage of Basecamp (FaultPress, our new bug tracking theme, is a perfect alternative for smaller development teams, especially with its amazing milestone management) to keep track of what everyone is working on & working towards. The reminders go a long way of adding that bit of pressure to get things done on time.

The biggest benefit we’ve seen in recent weeks [since the tweakage] is not necessarily in us meeting more of our deadlines, but that we’re building up a bit of a backlog of releases, which while they may not be public release-ready, they’re tasks that we’ve ticked off our list (allowing us to move onto the next set of tasks & challenges). This creates even more flexibility in our daily workflow & schedules, which is great both in terms of release cycles, dealing with emergencies and creating a more relaxed, creative working environment.

Here are the ways I’ve found to make and keep WooUsers happy…

1. Be Kind

The most simple of all strategies, be kind! Sometimes back and forth communication can be tough to deal with all day. If I’ve not had the best of days it’s tough to keep being helpful. I’m sure we’ve all experienced it before, perhaps I can best equate it with trying to show your dear mom how to use Google over the phone. Or better yet, explain how to sync anything or install any app… True test of patience.

No matter what though kindness kills, and it’s a good thing. It’s not anyone’s fault that I’m in a foul mood, and often a user comes out and says they know can be a pain if they don’t understand something. I always try to give the best help I can and smile while doing it. Usually once a problem is solved we are both happy and thankful for each others patience. Using a smily face or two always helps.

2. Go The Extra Mile

When does going the extra mile ever hurt anyone? We care for our WooCommunity and often go the extra mile to leave with a satisfied customer. For example, something I often like to do is help people testing themes on our Theme Playground. Since many haven’t purchased a theme yet, they don’t have access to theme docs or support forums. When we receive emails from people struggling on the playground I will take a screenshot of the theme documentation they need and send it their way. I also try to manage every problem I can for users on the playground. Some have trouble setting up a theme, others can’t figure out a little custom css they’ve done, etc…

We’re known for great support, and the Theme Playground shows our willingness to go the extra mile and let you try our themes. I try and provide the support before they’ve even purchased a theme.

3. Be Available & Prompt

I keep our inbox, Facebook, & Twitter accounts open just about all day everyday, including during the weekends. This lets me take a quick glance and see if there is anything I can take care of while I’m doing something else Woo related. In fact I just fired off an email to Ole, while typing this. (Hi Ole!) I like to respond as quick as I can, and as we outlined in a previous post, we’re striking a balance between a quick answer and a helpful answer. I respond as quick as I can with the best answer I can. If I don’t know the answer, I’ll let you know while I find one.

The culture in the U.S. is very much centered around getting things and getting them now, I try to help alleviate the wait by being available and prompt to answer. Even if I say, “Sorry I don’t know the answer but am looking,” WooUsers seem to appreciate the honesty and transparency.

4. Be Real & Understanding

Having sympathy, empathy, or any ability that to perceive people’s emotion is something I work on every day. It’s good to be able to tell when a user is frustrated or happy. Both types of emails include a lot of caps and exclamation marks, but to tell the difference is key.

This definitely is a big deal when interacting with our WooUsers. We use tags on Twitter to show which one of us you’re talking to, we leave comments under our real names on the blog, etc… We hope this lets you get past our facade as WooThemes, even though that facade isn’t inherently bad. It’s just better to know a real person that understands is helping you with your issue or concern, and not our WooBot… I’ve found that being understanding and showing real emotion often leaves WooUsers happy, even if we couldn’t solve the problem.

5. Free Stuff

Although it’s funny, giving away free stuff always makes people happy. Sales and discounts could count under this as well. Free or discounted items are always a good way to give some thanks back to our WooUsers and make them happy. Nothing else could be said about free stuff, except people LOVE it.

I utilize these tactics everday. By themselves or combined, one of us can usually leave with a smile on our face. Hopefully though it’s both of us.

Got any idea that you think would make more of our WooUsers happy & satisfied customers? Sound off and leave a comment, I’ll consider adding it to my repertoire.

So last week I decided to take some time off and spent a couple of days at a nature reserve in the Western Cape with my wife. No mobile reception, minimum internet and a bunch of non-work activities (i.e. sleeping, relaxing by the pool, etc.) to keep my mind out of work. Blissful & some much needed downtime just to recharge the batteries.

But that’s not the point of this post… During our time there, I checked in on WooHQ activity, because I’m the curious kind, and also because I never manage to completely shut down when away on holiday.

I saw that Cobus had posted some mockups for a new top-secret project (see these two mockups if you’re curious) and was asking for some feedback. Since I was very close to this specific project, I immediately felt the urge to jump into the conversation to “make sure” that my vision and ideas were being implemented. Yet I stopped just there…

See, whilst I’ve never been much of a micro-manager myself, delegation has been one of the skills that I’ve had to teach myself in the last couple of years. This has also been *the* skill that I’ve found the hardest to fully implement, as this is probably just not the way I’m wired naturally. And it was my “struggle” with delegation that created the urge to be involved in that conversation even though I was supposed to be away, enjoying some downtime.

I realized at that point though, that I had so much trust in the whole WooTeam (both individually & as a unit), that I didn’t need to be involved. In fact, I felt comfortable that my contribution to that conversation up until that point, would’ve been sufficient in communicating my vision; thereby leaving the implementation to the team. And this is why, as co-founders we’ve always valued trust over-and-above any other team dynamic or characteristic.

Here’s the point I’m trying to make: If – as co-founders and owners of our business – we didn’t trust each other to make the best decisions in our absence or trust the team to implement our vision in the way they think best (and without us micro-managing), we’re simply doing it wrong.

No one wins when there’s a person who needs to have their hand in every single pie, from start to finish. Delegate and then simply trust instead.

This question popped up recently, whilst we were scoping out some new functionality – the working title is The WooThemes Concierge for now – that we hope to add to WooThemes.com in the next couple of week. The functionality is basically aimed at making the lives of our users – especially prospective users – easier when they are faced with the “challenge” of deciding which theme to purchase (which has become more difficult, considering we have 90 themes as I write this).

If I was an outsider and I asked myself the same questions (as above) applied to this project, I’d probably like to know:

• How the WooTeam decided on committing resources to this project instead of alternatives;
• What the alternatives (direct or indirect) were; and
• How this decision was evaluated in terms contributing to a return on investment.

So here’s an overview of how we made this decision…

The Initial Idea

To be honest, the biggest part of our reasoning in terms of committing to this project relies on our belief that this functionality is unique (both online and in terms of what our competitors aren’t doing) and the benefits to our users are obvious: increased usability generally contributes to greater sales.

Making a decision based on one’s “belief” that it’s a good idea seems like a flimsy basis on which a company should make a decision, but we’re obviously experienced and by now have an inherent gut-feel of which projects are viable. We would however not make a massive, game-changing decision that could significantly alter our business purely on gut-feel. That’d just be silly…

Which is why we also combine this gut-feel with the knowledge that increased usability is a significant benefit to our users. Combining an empirical metric such as increased usability with a belief / gut-feel that the project will deliver additional (unquantifiable) value, gives us a much stronger basis from which to evaluate this decision.

Weighing up the options

Now that the team has agreed that this is a good decision (i.e. we believe the outcome will be positive), we need to evaluate it against alternatives; it’d be silly to commit to a project that would only increase sales by 1%, if we can invest the same resources and elicit an increase of 10%. This is however where things get a tad less black-on-white, considering that whilst some outcomes are easily quantified (increased sales or traffic), others aren’t (brand awareness or the effect of enabling a better user experience on one’s website).

Most projects that we’ve undertaken will have both quantifiable and unquantifiable outcomes, but will also generally lean towards being more quantifiable or more unquantifiable.

For example: when we design & develop a new theme, we can easily track the return on that investment by looking at the sales of that specific theme. But another well-trafficked blog may write about our new theme, which results in brand awareness, which in turn results in a prospective user buying another theme from us 6 months down the line. The first outcome is therefore easily tracked and “allocated” to the development of the theme, whereas it’s difficult to determine that brand awareness (as a result of the development of the theme) resulted in the purchase of another theme.

On the flip-side, we’ve also been doing a lot of work recently on things that don’t result in an easily allocated or quantifiable outcome:

• We’ve spent a lot of time improving our tutorial videos since the turn of the year. Do they generate more sales? We don’t know… But we are sure it provides more value to our existing customer base and by making the videos available publicly, we think it serves as an alternative marketing campaign all by itself.
• Our Tumblr2WP migration tool doesn’t generate any direct sales by itself, but the sales of our tumblog themes seem to be up since the launch of this free tool.
• Early last year, we contributed a significant chunk of code to the WordPress core, which eventually resulted in the new Menu’s functionality in WP 3.0+. We’d bet that 99% of WP users that use this functionality every day don’t even know that this was our code, yet the immense amount of kudo’s & publicity that we did receive surely played a significant part in our growth last year.
• This post is part of our WooLessons series, which most definitely doesn’t generate any direct sales. But we believe we’re adding value by sharing our knowledge and experiences, which in turn means we can possibly attribute part of our recent growth to increased traffic as a result of these blog posts.

There’s quite a bit of seemingly contradicting information and considerations listed above, which should just emphasize that it’s generally quite a challenge to make big decisions within our business. In the next step though, we’ll try share our philosophy when we made this specific decision…

Making the decision

In making the decision to work on The WooThemes Concierge, we based our decision on the following considerations:

1. Our capacity is always limited, which means we needed to consider the priority of this project. To prioritize capacity for this, we needed to figure out what was the resources required to produce our intended result and then weight that up against the potential return.
2. We decided that this was a relatively straight-forward project – thus low-hanging fruit – and conceptualization to launch shouldn’t take too long.
3. Determining the actual “win” or return in this regard was harder, as we had no actual data to base this decision on. We are however firm believers in adding as much value as possible, as this strategy seems to have paid off really well in the last couple of months.
4. Beyond measuring an actual return on investment, we felt that this project was unique and that we would hopefully get some nice publicity from this. We don’t just want to be followers, but instead we’d like to be thought leaders that inspires unique imitations of the things that we do at WooHQ.
5. This is a cool, fun project in which we can apply our design & development skills in a more out-of-box way and thus allowing to focus on creativity more so than just pleasing customers. Not only does this afford everyone a bit of a breather in terms of theme development, but it just rejuvenates our own, internal thought-processes which should have longer term benefits to the WooCommunity (these thoughts obviously make their way into our themes eventually).
6. We also didn’t have to prioritize this project over theme development, which can still continue uninterrupted. Instead we just had to decide whether we wanted to prioritize another, similar project higher than The WooThemes Concierge.

The Take-Away

Ultimately it’s never easy to make these decisions, since there’s so many different ways of looking at them, so many different considerations to account for and the most important: each individual or company will attach different amounts of value to different outcomes (especially the one’s that are inherently less unquantifiable). There’s therefore no way we could publish an authoritative blog post about how you should be making your decisions…

We do however hope that by us sharing our own thought and decision-making processes with you, we’ve shown you that there’s more than one basis on which you can make decisions. Money or increased sales shouldn’t be the be-all & end-all for every decision, and whilst this is obviously something we hope to achieve more often than not, it has never dictated our decisions.

Initially we thought that it’d just be fun to share a bit of behind-the-scenes insight into the inner workings  of the WooTeam, whilst also generating some traffic to the site (this was probably our main motivation to start this up). Since the first WooVille went live though, we’ve found that the series has been a great addition to our workflow for a couple of reasons…

We hope you get to know us better. Sometimes joking about oneself is the best way to kinda be honest and share insight into who you are. And that’s what we’re attempting with WooVille: it’s not meant to be corporate, but instead it should give you an idea of who we are and how we work. We think that our customers enjoy the fact that they know who is behind the computer, the e-mails they receive, support tickets being answered and themes being released. It’s just our way of making sure we’re as personal as possible. 

We don’t want to take ourselves too seriously. Most businesses are really boring and have crappy policies which they have to follow or else. With WooVille, we’re hoping to show that we don’t take ourselves too seriously and that WooThemes is our passion before it is our jobs. We can smile and have a bucketload of fun whilst working incredibly hard; these things shouldn’t be mutually exclusive.

It’s funny & light-hearted. Work tends to get a tad serious every now and again (regardless of how much you love your job) and our once-a-month discussion about the ideas for a new WooVille comic definitely does a great job at lifting the moods. Normally this is just a bit of time for joking around, talking trash and not working.

How does your business look to the outside world?

I guess that’s the question all business owners should ask them every now and again. For us it has become really important to really connect with our users and give them the opportunity to get to know is. WooThemes is a brand and whilst the  brand is not a real person, it doesn’t have to be dead.

Instead we’re really focused on doing cool things – with WooVille being a great example of this – to give our brand as much colour and depth as possible. None of this is an exact science of course, but at least nobody can accuse us of being mysterious…

We have however never enforced a 2 vs 1 situation that is sometimes just natural when 3 individuals have to make a decision. Instead we’ve preferred to spend more time discussing our decisions and whilst it would be impossible for all 3 of us to be similarly passionate about each decision, we at least want everyone to feel comfortable with the suggested decision(s).

There thus is no majority vote at WooThemes and we’ve never used the 2 vs 1 situation to force a decision through. This just isn’t the way we do business.

It’s About the Relationship

One thing that has always been pretty obvious to us, is that our relationship with each other – both as co-founders and friends – is paramount to the success of WooThemes. We’re not the most talented group of co-founders you’ll find online, but we’ve worked really hard and we’ve worked together (two very important characteristics we believe).

A result of our great relationship has been that our combined personalities have become the voice, image & personality of WooThemes, which means that our business is simply an extension of us. By making sure that our relationship is our most important asset – and not compromising on those by forcing a 2 vs 1 vote down someone’s throat – we’ve built a flourishing business which we absolutely love.

You’d think that after working together for 3+ years now, there’d be a few fights at least, yet we’ve quite easily navigated our way through potentially sticky situations by not invoking majority voting. Yes – sometimes this means discussions are drawn-out and decisions take a little while longer to make, but it also means we’re protecting our biggest asset: the team & our relationship.

Ryan created a whole “Hire me WooThemes” page, which included an incredible video – which he shot & edited himself – to sway our opinion and hire him instead of the other candidates. So sure – we realize that not every candidate had Ryan’s videography skills and it goes without saying that our decision to hire was obviously not made as a result of his videography skills (as this itself doesn’t – yet – seem to be a beneficial asset to the WooTeam), but heck did that video sway our decision-making so much…

But, what’s in a video? We’ve obviously never met Ryan, which makes our hiring process a tad more complicated since we can’t actually have a sit-down and judge the character of the person applying. But with the video we could see two things:

1. Ryan is an unique individual. He wasn’t scared to put himself – as a person and not just a CV – out there and *really* apply for the job. Things could’ve just as well worked out differently if we didn’t like the video or the person it featured, but the video was the closest to a real-life “interview” we could’ve had with Ryan. We loved how he wasn’t afraid to be himself and how he communicated that in a really unique & awesome way.
2. The passion was evident. Have you ever made a video to persuade a company to hire you? Probably not (I haven’t either)… But Ryan invested a lot of energy to get the job, which makes us think he badly wants the job and would thus make a good addition to the WooTeam.

We’ve hired many different people in the past and none of them made a “Hire Me WooThemes”-page or video and that was fine too, because we could judge their individualism & passion in a completely different way. With Ryan though, these made a big difference to our decision.

Hiring for Passion & Individualism

Ryan has only been in the job for a week and from early evidence we’ve just added an immense asset to the WooTeam. We thus believe that our focus on hiring an unique & passionate individual has already paid off and will continue to be a great contributing factor to our continued growth.

Here’s a couple o reasons for you to value passion & individualism in your own hiring decisions:

• Avoid clones / robots. There’s a balance to be struck in the composition of every team and generally we’ve firmly avoided having clones and robots on the team. The  beauty of the WooTeam is that we’re 10 very different individuals with a shared passion, interest & goal (WooThemes & everything that includes).
• Thinking for yourself. The last thing we want is to micro-manage anyone on the WooTeam. Instead we want everyone to take their own initiative, have an opinion on how things should be working and thus contributing their unique value. If we just had employees who echoed the personalities of the co-founders, our ideas would never be challenged and, as a company, we’d probably never evolve.
• Passion breeds so much value. When you’re passionate about something you don’t mind working hard and ideas (which is the cornerstone of innovation & evolution) are pretty easy to come by too. In addition to that, WooThemes tries to be a very user-centric company and our passion to deliver amazing experiences to our users (both via our products and our interactions with the WooCommunity) and passion is thus very easily translated in this way.

We hope that you can see these characteristics in your interactions with the WooTeam and we are excited to have Ryan being our evangelist in communicating this to the WooCommunity.

What do you think? Is this all smoke & mirrors? Or are we actually walking this talk?

We realize that most of you reading this will sit there and think “Sheesh, I wish I had 10 team members to help me out” and that’s a valid point, but we obviously have a growing, hungry user base to support. Consider that there’s 45 000-odd of you in the WooCommunity, which means each member of the WooTeam is roughly responsible for 4500 users (or “clients”), quite a daunting thought…

The problem isn’t necessarily insuring a memorable, and positive experience for every single WooThemes user, we have a constantly evolving membership system for that (more on that soon), but it’s finding the balance and time to spend on developing and releasing new products. If you consider that we’re hitting our goal of 2 themes a month relatively easily (along with the fact that we’re continuously releasing improvements on the WooFramework / old themes and the themes we’re developing are becoming more complex), we’re not doing a bad job of managing our time.

We have a simple strategy in this regard: we have to budget & prioritize our (limited) time accordingly. Here’s a few thoughts on how we go about this…

How to Budget & Prioritize

We’re sure that every team will do this differently, but these suggestions are what we implement in deciding which projects / tasks to tackle on a daily basis:

• Low-hanging fruit. This is something that I’ve written about before and something that I’ll emphasize again: there are indeed easy wins in your daily to-do. The idea here is that sometimes something that only takes a minimal amount of time to finish has a bigger-than-proportionate benefit if finished / released. For us this is generally releasing a super-sexy business / magazine theme, which doesn’t take long to develop, as we know the WooCommunity absolutely loves them, which then gives us time to invest in projects that take a little more time.
• What’s the biggest win? This is related to the above (or at least it helps in that decision) and our challenge is figuring out what the benefit of finishing something will be. This benefit or win can come in a variety of shapes & sizes, and we generally release stuff for a couple of different reasons: because you’ve requested it, diversification of our products, marketing / publicity value or we’re being innovative and want to pursue new avenues. Figure out which of these you’re aiming for and then figure out which will have the biggest win in the short and long term (which is our next consideration).
• Short vs long term. We always attempt to strike a balance between finishing things that will benefit the WooCommunity now, versus working on things that will only have apparent value in the mid- & longer term. This ties in closely with our philosophy of low-hanging fruit and allows us to pursue the easier wins, along with the stuff that will eventually shape the future of WooThemes. A good example of this has been our tumblog themes, which we rolled out long before we got around to releasing our iPhone app & a proper migration tool.
• Continuous improvements vs new releases. One thing that we’ve seen time and time again is that releasing more themes doesn’t necessarily add value to the WooCommunity or grows / evolves the company (which means we’re unlikely to increase our release frequency). We therefore spend a lot of time improving the stuff that we’ve already released, which adds value to so many existing users. We also believe that this strategy shows that we are fiercely loyal to our existing users, and not just chasing the acquisition of new users by releasing new themes.

This strategy has really served us well in the last couple of years, since we’ve been able to limit the growth of the WooTeam (i.e. be more conservative) and that instead of committing to every new possible task (and simply throw man power at the problem), we’ve simply prioritized what we need to work.

And heck that is hard at the best of times. But we’ll much rather have that difficulty on a weekly basis (trying to figure out what we need to be working on), then risking the future of the company with an aggressive growth strategy of the WooTeam, which generally only inflates our monthly expenses.

So having said all that, I’m going to tell you what works for me and in general I try to use the bare minimum to get stuff done here at WooThemes. With so much code to write, I don’t want a million apps and settings to go by – I just want to login, write code, and deploy.

So here’s my setup…

Hardware:

• MacBook Pro
• 22 inch external LCD
• Logi-tech wireless keyboard mouse combo – ‘cos those Apple keyboards are too small for me
• iPad for forum/email support at home

The Woo Workstation

Software

General Development

• Coda – I cannot even describe how much I enjoy Coda, it just works and doesn’t crash! Plus it has FTP and Terminal all in one so it suits me great!
• WordPress syntax mode plugin for Coda is great for when you can’t remember your WordPress functions.
• I use SVNx for a general overview of our SVN repositories, but I use terminal most of the time anyway for SVN tasks – the other guys use Versions as they don’t need to be using Terminal or SSH.
• I use MAMP Pro for its customizability, but you can get by with just regular MAMP though.
• My main WordPress setup is a single WordPress install with NetWork enabled, and a site for each theme with each having its own unique content.
• I test using Firefox, Safari, and Chrome – frontend design testing is done by the frontend guys so I don’t need IE (thank goodness).

WordPress Specific Settings

• I generally like a clean WordPress install, however I’ve decided to trial these 2 debug plugins, Debug Bar and Debug Bar Console. They give you a nice overview of what’s going on under the hood of your WordPress install and could be usefully for optimization.
• Other than that, you can follow the WordPress debug settings, and/or I generally have the following debug setting enabled though:
  

But basically I spend most of my day in Coda writing/upgrading/fixing logic in our themes and plugins, or reading forum support threads.

And that’s the life of a WooThemes developer! What do you have in your “batbelt”?

We’re firm believers in using our own products, which means that exactly the same WooFramework that goes into our themes, is the one that WooThemes.com has been built on and is powered by. We believe that this best communicates our trust in the themes that we develop, and makes for a healthy marketing campaign.

Three examples of us actually using our own stuff:

• We recently hired Ryan as our new community manager and we used our jobs board (the theme is not ours, but we’ll save that for another blog), WooJobs, to advertise the position and handle the applications. We got 34 top applications in the space of 4 days and managed to hire an incredibly talented individual to the WooTeam in less than a week.
• The WooThemes Showcase has been using a slightly modified version of Snapshot (a free theme we released back in the day). The Showcase these days features almost 1500 awesome modifications of our themes and is still running strongly (probably due to the continuous improvements that has gone into the WooFramework which powers Snapshot).
• For our Express iPhone App marketing we use a modded version of our Apz theme to showcase it’s features and act as a sales tool.

There isn’t a much better testimonial than that, is there? 

“The Marketing Campaign”

Marketing campaigns often give off the wrong impression – making a company look somewhat desperate, as if it is trying too hard to sell their product/service to you, and lack the kind of conviction that a proper, personal endorsement invokes. 

When we’re putting our products out there, we want to feel confident about putting our name on the packaging, and proud of the work we’re doing. The only way for us to verify this, and to keep our checks & balances in order is to use our products in real life scenario’s as much as we can.

Another great reason for us to invest in this approach, is obviously due to the nature of our products themselves, which we market as the starting point, or the building blocks for all your new projects. It is a way we get to think like a client and the requirements they might have. We then build a better product for our customers.

Consider this our official stamp of approval on all of the things we’re releasing and creating in & around WooThemes.

The way to achieve this, is to balance out the specialist skills by also diversifying the skill set you have available on your team. This should be done in two ways (using the example of a web design / development agency or most online startups):

1. Make sure that you have a good balance between designers & developers on the team, but furthermore a balance between designers who prefer Photoshop over CSS, and CSS over Photoshop. Similarly make sure that you balance out PHP or WP or jQuery skills on the team, so that you can cover all of your bases equally well.
2. If you have a developer who is great at PHP, have a secondary developer who is almost as great at PHP, but prefers to do mostly jQuery work. You do this as a contingency plan to make sure that if your #1 guy is away from work for weeks (due to illness for example), the team can still function without him or her. Neither diversity or specialism should come at the expense of making sure that the team can still function when some of the team members aren’t present. That’s just silly & semi-suicidal.

For us, the best example of how we apply this at WooThemes is that 2 of the 3 co-founders can take a couple of days off, without hampering the business as the 3rd co-founder is capable of dealing with everything. Sure, we’re less productive then, but as a basic contingency everything can still function properly and our customers don’t lose out in any way.

Looking around the web, you’ll see that all of the most prominent platforms (i.e. the one’s with thousands / millions of users like Google, Facebook, Flickr etc.) understand one thing: to service that amount of users, you need to be designing & developing a product that is usable in the hands of their community. This means that things like a superior UI becomes paramount in their ability to influence both the emotions & experiences of the users whilst they are interacting with your product(s).

Since they are however hosted platforms, the users never touch the code behind the UI, which means the UI itself is purely a question of how well the designers & front-end developers have executed their jobs. Sure, we all know that there’s obviously thousands of lines of code that are making that awesome UI do its job, but the users themselves never comes into contact with that code. Which simplifies the whole situation greatly…

Code by WooThemes

See with our own products, we don’t have that “luxury”; our users generally get their hands dirty with our code, really getting in there, breaking it and building it up again. That is both the nature of our products (being self-hosted by our users) and the #1 reason our users are buying our products: they want to modify & use it in their own way.

In our minds, our code itself also needs to represent our fanatical approach in terms of designing everything in and around WooThemes. We’re sure that there’s a whole bunch of developers that would agree with us that code is poetry (borrowing a slogan from WordPress itself) and perhaps we wouldn’t represent our code and coding practices in such an abstract light, but there’s definitely a few things that we do with regards to our code to present it in a more designed way…

1. Clean Code & Coding Standards

We obviously adhere to all of the most well-known coding best-practices in terms of indenting our code properly, including comments as much as possible, div id/class naming conventions, etc. In the last couple of months, we’ve also tried to code our themes to adhere more and more to native WP, which means that we’ve managed to reduce Woo-specific code / functions and have instead preferred to use native WP alternatives as much as possible.

When we however write custom WooThemes functions, we try our best to write it in such a way that it makes sense in English. One example of this is to not use the shorthand method of writing IF statements in PHP, but instead structuring the statement in such a way that it can be easily read & understood by a human. Our users aren’t machines and we try to simplify things accordingly for them.

2. Standardization via the WooFramework

The WooTeam consists of 9 people, all with different coding styles/techniques. We have however tried to standardize this as much as possible, firstly by using the same “starter theme”, which means that the HTML & CSS structure is similar across all of our themes.

Beyond that every single theme in our collection is powered by the same set of core functions, which has become the WooFramework. This helps our users in that they can customize the same thing in a similar way within any of our themes.

3. Balancing Theme Options vs Clean Code

Ever since we started the trend of including theme options with premium themes (way back in November 2007, when The Original Premium News launched), we’ve seen other theme providers just piling options into their themes (it seems that the more options you have, the better your theme is, right?). Yet, when we set out on this path, we never really envisioned things like this…

We believe that theme options are a great way to allow users to accomplish certain tasks without having to touch the code, which is especially great for the not-so-technical users. But in the last 3+ years of developing WordPress for many users, we’ve found it absolutely imperative that we need to question every single theme option or feature that we include in our theme.

Why? Theme options and “advanced” features are directly proportional to the complexity of the code of a theme. Take this example from Fresh News, which is the code we use to allow our users to upload their own Custom Logo from the backend:

    if (get_option('woo_texttitle') <> "true") : $logo = get_option('woo_logo');

    
        
    

If we didn’t include the same option to specify a custom logo from the backend, the same code would be a little less complicated:

In the second snippet you’ll see that we there’s no more custom WooThemes code and that the PHP snippets are default WP template tags, which makes this segment of code more generic, and therefore easier to customize for a wider array of people.

We’re not suggesting that we’d ever exclude a theme option like this from our themes, but we have become more and more selective about just including every single option imaginable. A famous quote about design rings true: “Art is not about what you include, but instead about what you are excluding.” It’s easy to add options to a theme, but it’s much harder to develop a well-balanced theme.

Don’t Fight the Code

This post was inspired by a user comment, which included one of the main reason for the user’s love of our themes: “Users don’t have to fight our code.”

And that is exactly where our heads are at with regards to developing our themes in a user-focused way. We have a team of hotshot developers who can pull off a bunch of amazing things, but that doesn’t necessarily that those kind of additions would benefit our users. Our users are most definitely customizing the heck out of our themes, getting their hands dirty in our code, which means that we need to take the necessary action to ensure we make that task easier.

Not more difficult by complicating our code with additions that only we understand & consider to be awesome.

We bet that most of you will share common testimonials of bad experiences that you have had with clients: demanding clients, crappy jobs with very limited budgets, clients who believe they’re the better designer, etc. In all of these cases there seems to be a recurring theme of feeling limited as the designer or developer on the project. Sound about right?

Well, this is something that we’ve attempted to change at WooThemes.

We have 40 000+ “clients”, so we too can attest to having some “limitations” imposed on us due to the demands and requirements of our WooCommunity. But we have actively tried to create as much space and freedom as possible for the WooTeam, so that they can go about their jobs in the ways that they are most passionate about.

Nowhere is this more apparent than our core development process; whilst this is sometimes mundane (bug fixing bleh), it is mostly awesome because we develop a lot of fun stuff along the way. Jeff & Matty (respectively) – who make up the heartbeat of our core development process – had the following to say:

The other thing in my opinion is freedom of creativity – I’ve found my skills have really improved a bucketload by having the freedom to try new stuff without fear of having to clock hours and meet deadlines.

Freedom of creativity is a definite plus factor in our job roles, in that it affords us the opportunity to explore various avenues, and ultimately release a better product as a result of those explorations.

The result is innovative features that benefit the whole WooCommunity. Here’s a few ways in which we enable this space, freedom & creativity:

• We trust & respect individual skill & opinion. This means that if either Jeff or Matty believe that X, Y, Z is the best way to solve a problem, the rest of the WooTeam will back them in that regard. Same goes for Cobus on the design-front. We (mostly**) don’t try to second guess each other.
• We try to schedule & prioritize work in such a way that there’s always a balance between mundane & fun. We can never get away from the more mundane support/browser testing/bugfixing tasks, but when intermixed with projects that excite, those tasks become more bearable.
• We make WooTeam members accountable for their projects & related decisions, thus allowing them to take the lead (and ultimately the credit) for the things they deliver. You’ll see this quite clearly in terms of our blog posts, where we try to emphasize who has been responsible for anything that leaves WooHQ.

Whilst there’s probably a couple more things that we do to enable the WooTeam (like this), the above mentioned covers the basics that we believe are integral in making sure that creativity is valued above most other things. It simply delivers *much* better results.

**We say “mostly” purely because sometimes design is too subjective and the team need to test it from a usability standpoint. In the end though – once all opinions are more aligned – it becomes the responsiblity of one of the WooTeam members to get the decisions implemented.

It’s not just about publishing blog posts either; by admitting to a screw-up via e-mail is just as hard. If we had a choice, we’d want to be perfect in every situation, and would prefer all of our users to be oblivious to the mistakes.

Eliminating mistakes completely (as a company) is impossible and trying to contain them / keep them secret is an exercise of volatile PR. We’d rather not even try that… Instead we believe that these kind of things are better said and admitted to, than just ignored, and figuratively speaking – a layer of wallpaper stuck on to cover the crack in the wall. We have found the WooCommunity to be appreciative of our transparency in this regard.

Under Rug Swept

Richard Branson has been quoted as saying that “there’s no such thing as bad publicity”. When we apply that principle in our interactions with our community / audience, we do so publicly, without trying to sweep our dirty laundry under a rug.

The best example of this would be comments on the blog: if someone complains, questions us or criticizes us about something we’ve done wrong, we just interact on that point right there & then. No need to pussyfoot around the comment; if it’s irrational and invalid, then we’ll say so too. Most companies tend to want to un-approve that comment and will (optionally) engage with the comment author privately, out of public view via e-mail.

On many occasions these interactions have actually lead to other WooThemes users joining the conversation in defense of ourselves. There’s just no better defense than having a massive clan of WooThemes users doing the debating based on their own enthusiasm and passion for what we’re doing. So much for trying to be a corporate robot, blowing your own little trumpet.

The Win

Customers love knowing what is going on and by communicating with sincere transparency, you are bound to earn the respect of your customers. Keep them updated – with the good *and* the bad news – at all times; they’re bound to support you regardless.

We’ve always believed that the mark of a great company is not how perfect they are (i.e. how well they avoid making mistakes), but instead how well they respond to making mistakes. Dealing with a supposed perfect company just makes one anxious of when the unsuspected screw-up will happen (heck, I’m a Apple fanboy, yet I probably feel this way about Apple).

If you address these issues in a sincere, transparent & objective way, you’ll also be developing a voice for your brand. Develop the right voice for your brand with these interactions and you’ll be able to leverage the respect, trust & loyalty of your customers to further grow your business.

We’ve found that our users are much better at telling us when they’re not happy with, and when we’re not doing something right, whilst the positive stuff is just silently enjoyed. This means that unless we look at things holistically, it would be easy to get a skewed view of our user perception. It is however a well-known (online) fact that people that complain, do so very loudly, whilst compliments are a tad harder to find.

Beyond our ego’s and the feel-good factor of knowing our users are happy, there’s a different challenge to this situation: the decisions we make. If we make every decision based on the “unhappy voices”, we’re probably alienating the silent, but happy majority of our users that don’t want us to make decisions that will change anything / everything. Magnus said it best recently:

And most importantly, users will tell you when they are unhappy, but not so often when they are happy. So don’t panic.

So don’t sweat it. Focus on interacting more with your happy users, and be objective about the negative feedback that you receive. Your time is much better spent proactively and on keeping the happy users even more happy; don’t ignore the negative users, but don’t let their voices and opinions run riot either.

Since the very early days of WooThemes, we’ve always focused on releasing the odd freebie, which has normally been in the form of free themes, icon-sets and more recently our WooTumblog plugin. There’s currently 12 free themes available, from our total collection of 86 themes, which isn’t a bad ratio (one out of about 7 themes are free) we believe. And the beauty of those themes, is that they’ve been released completely free for you guys & girls. Built on the same WooFramework that powers all our themes.

But how much do those themes cost us?

If you consider that we’ve had about 400,000 downloads of our free themes this year already, you’d think that there are quite a few blogs out there running our free themes. And yes, you can rightly point out that this is great publicity for us, and that at least some of these free users have converted to paid customers (that’s part of why we release free themes). But is there perhaps a cost associated to this for us?

We get so many e-mails on a daily basis from users who are trying to get support for our free themes, that either want to modify them, or are simply struggling with one or two features. Whilst the free theme’s documentation is publicly available, that is also unfortunately the only resource that we can commit to users of our free themes. If we had to provide technical support to 400,000 users free of charge, we’d soon go out of business…

And therein lies the “cost” for us; perhaps it is better described as a slight risk… When we end up not answering the questions of our free users, we run the risk of losing them from WooThemes forever. Even though we can try explain our reasoning, and the rationale of our support policy, we still risk alienating them enough to have them never come back to WooThemes. That’s the double-edged sword: support them and run the risk of over-committing time / resources or don’t support them and potentially lose them forever.

So if you have used any of our free themes, always consider the behind-the-scenes considerations, risks and associated costs that we’re faced with offering something for free!