Ideas
In traditional workplaces, ideas that don’t come from the product manager are not typically taken into account. At CakeMail, we think differently. Anyone can come up with a good idea – and if it’s a good one, it will be implemented in the product. We also listen to our customers as much as possible. Even though we happen to say no often (as you should – saying no is a powerful thing), if the idea is often requested, it might have a good chance of being put into the product.
Of course, we also have a product roadmap. Contrary to most companies, this roadmap is not set in stone for a given period of time. We know where we are going in terms of product strategy – but the priority for developing new features can change at any time. We try to stay agile as much as possible.
The roadmap is also not public. We don’t want to commit to a date, and we don’t want to over-excite our customers. They just know that every week or so we make changes to the platform, and every two months, big new features are available.
Wireframes
Every feature we add starts with a wireframe, or a mockup depending on the situation. Wireframes usually start as hand-drawn scribbles and end up as a full wireframe done with the fantastic Axure app. I prefer Axure over other wireframing tools because it’s so easy to create a working prototype in minutes, with on-mouse events, keyboard validation and multiples states on each page.
As soon as we have a working prototype, wireframes are uploaded on share.axure.com, letting teamates review the prototype and make comments. We don’t use the commenting feature of Axure Share – it’s not convenient at all. We simply share our comments by email most of the time, in a Basecamp project (their new version is great) or if necessary, in a Google Doc. From there, several iterations are made on the prototype – as much as necessary. As soon as we are happy with the feature, the designer comes in, and creates the design in Photoshop or Fireworks. The designer will also put his personal vision of the feature in the mockup – and that’s ok.
If you have good Axure skills, you can produce extremely precise wireframes in no time, using homemade librairies of your product. For instance, we’ve created a CakeMail library that contains most of the design elements we need, like popups, buttons, titles, links and so on. This way, new screens can be created in a very short period of time – and people won’t even notice it’s a wireframe, as it’s an exact copy of the application itself. However, if the feature is a new screen, a new page on the website, or anything that we don’t have in the product so far, we won’t have any other choice than to create mockups for it from scratch.
There is lot of debate at the moment regarding Photoshop/Axure vs HTML mockups. Really, it does not matter – use the technique you are the most comfortable with. It’s ok for a designer to design in Photoshop, and it’s okay for a front end developer to build an HTML version of the design.
Github
Github is a very important part of our workflow. Basically, everything evolves around it: bugs, comments on new features, design,… And it hosts our code, of course. As soon as a design is ready, we create an issue in Github. The issue contains the design and a very brief spec (nobody likes to read pages of Word specification). Each issue is assigned to a developer, a milestone and one or more labels. That way, the developer is aware that he is in charge of the feature. He also knows if he has to code it now (based on the release number) and depending on the label, knows if it’s urgent or not.
To describe a feature or a bug, we need images in the ticket in Github. It is crucial and speaks much more than words. We store all our images on Imgur. To make sure images are not deleted after a while, we have pro accounts. To speed up the process of putting an image in a ticket, I use a Chrome extension that lets me drag and drop an image from my Desktop to my Imgur account. Once the image is on Imgur’s servers, I copy the link and use Typinator to paste the link formatted as a Markdown link. Typinator is basically a text expander that lets me save thousands of keystrokes. To paste an image in Github, I simple type iimage and it generates  automatically. It’s awesome.
Localization
Once a feature is finished, we can start entering strings in our internal localization tool, our so-called i18n portal. We officially support English and French, but we have many more languages that some of our customers support themselves. If your webapp supports localization, then you know it can really be hard to manage. Because there was no elegant translation solution available on the market, we decided to create our own. Our tool works pretty well: users can add or update text strings that then get approved by the person who is in charge of the locale. Then, each time a string is modified in the master file (English, for us), all the other languages are prompted to update these new or updated text strings as well. Last but not least, you can push all the strings in production with a single click of a button.
Support
After this process, support comes in and prepares documentation for the new feature, which will be available to everyone in the new knowledge base we launched earlier this month. This new tool is pretty sweet: all we have to do is to update markdown files, push the changes to Github, and few minutes after, it’s live.
Announcing features
Once it’s live, we write a release note for the new feature and publish it to the release notes website. This way, any one of our customers know exactly what we’ve added to the software. As much as possible, we try to document the changes we’ve made. For bigger changes and major versions, we’ll blog about what’s been added in more detail, and send emails to our current customers and other opt-in subscribers so they’re aware of what’s new.
The delicate balance between creating your own tools and using existing tools
In the last few months, we’ve had to create multiple internal tools to help speed up our workflow, and especially to empower non-technical people with tools they can use themselves. We could have used existing tools – but most of them were not suited to our specific needs. It’s a decision that each company faces. When deciding on tools, we always ask ourselves these questions:
- is there an open source solution that we could use? If so, what is the hidden cost of using it (i.e. managing the server, fixing bugs, etc…)?
- is there an existing SaaS product that is not too expensive that could solve the problem?
- how much time would it take to create it ourselves?
The choice depends on multiple things: the urgency of the problem, availability of the dev team, budget, timeframe, culture of the company. We’ve decided, for each of our cases, that it was critical to be able to manage each problem ourselves.
