RevUnit

Over the next few entries, I've sought out to outline what so many young companies overlook: basic retail metrics.

Sure, you have the right product, a great website, and a foundation for solid marketing strategy. However, this does not necessarily mean your business can be all it can be.

I’ve worked with eCommerce companies of all sizes and in a wide spectrum of industries. From a single merchant running his business from his garage, to mid-tier companies that have large bankrolls, and billion dollar operations with millions of products and nearly unlimited resources.

At the heart of the big retail players in the industry, beyond having a state-of-the-art website with professional models, photography teams and million square foot warehouses, comes one common factor – detailed and smart business analysis. Juggernaut eCommerce players did not get to where they are by just luck (well, a little luck). The one thing they have in common are teams of experienced buyers, sales analysts and financial teams working around the clock to ensure they’re keeping track and maximizing every cent they make or spend. If a company does not live and breathe by intelligent data analysis, they’re almost doomed for failure.

However, no matter what stage your eCommerce company is currently operating at, the metrics I’ll be discussing over the next few entries can help you build the business you’ve always wanted and grow in both the short and long-term intelligently.

This week we’ll be looking at a number that is the corner stone of retail metrics (in my opinion) - Gross Margin.

I think most people, if they’ve started a business are well aware of what gross margin is for the most part. However, let’s define it (as long as we’re at it):

Merriam-Webster defines Margin (in a business sense) as:

“The difference which exists between net sales and the cost of merchandise sold and from which expenses are usually met or profit derived”.

I think that’s a fairly straightforward explanation. So, to boil things down, it’s the difference between what you paid for a product and what you’re selling it for. Here’s the problem – You would be shocked (I know I was) at how many businesses pay almost no attention to this extremely key metric. I once worked with a fairly well established company with impressive sales numbers (with state-of-the art facilities) and ran a retail analysis for them only to discover:

1)    They’d never performed this in almost of a year of operation.

2)    Their gross margin was just over 1% in and industry that should be on average of about 25%.

As a career merchant, I nearly had a panic attack for them. Their entire sales model was based on always having the lowest price and they were doing very respectable sales volume. However, at what price? Good intentions aside, after receiving, housing and shipping each item I found they were actually losing money on every order.

In order not to commit this cardinal sin in your own business venture, this week we’ll be looking in detail at two key metrics: Gross Margin Dollars and Gross Margin Percentage.

Here the formulas:

Gross Margin % = (Retail - Cost)/Retail

Gross Margin $ = (Retail - Cost) 

So, what do you do if you notice your margin is in the gutter? Here are some basic tips I’ve picked up along way that have always guaranteed me a margin increase: 

1)  Mark Your Products Up: This one is pretty obvious, but look closely at what’s selling fast and take a look at your “Mark-up/Mark-down %” and “Sell-Thru” (which I’ll address in a future entry in detail). If your marked down items are selling fast, hit the brakes. This will not only ensure a steadier inventory, but also help bump up your GM based on demand.

2)  Margin Enhancement Opportunities: This is an old standard of about every major department store for the last few eons. If you deal with vendors, see if they have discontinued or overstock merchandise that they’d like to unload. Most of the time you can get discounts on them and either sell them at retail or at a markdown price that allows for higher margin and allows the customer to feel they’re getting a great bargain if it’s quality product. 

3)  Negotiate Payment Terms: If you have a good relationship with your vendor you can often ask for extended payment terms (I’ll address this in greater detail in a future entry when we get to the importance of monitoring cash flow in sales forecasting). Conversely, many vendors offer discounts for paying early. If you’re not quite established enough to walk into a meeting and demand a vendor gives you net 180 terms, try negotiating an early payment discount if you have the cash on hand. In my experience, many vendors will offers discounts up to 10% (or more) if you settle invoices before they’re due.

4)  Defect Discounts: Many vendors offer damage discounts (the standard is about 2% in my experience, although some will go up to 5% or more). Therefore, always try to request one before buying or negotiating your current terms. This is actually beneficial for both parties (since retailers don’t have to return the merchandise and vendors don’t have to deal with the hassle of disposing of it) and is an easy win to increase overall margin.

As we move into spring - one of my favorite times of year - I step outside to see if my family’s Boysenberry plants are coming to life.  My husband’s grandmother grew boysenberry plants for 50 years in California, and, when she started going blind, my husband brought clippings home from Arkansas to grow so that the heritage would not be lost.

These boysenberry plants were grafted from a blackberry, loganberry, and raspberry vine to make a wonderful new and hardy variety of berry that can grow even in places not ideal for berry vines.

What does this have to do with technology and the account manager versus product owner role?  Everything really.

There are five different areas that a product owner must have some expertise in or knowledge of.

1.     Client Services

2.     Project Management

3.     Technical Architecture

4.     Strategy

5.     Creative Insight

The Account Manager role is usually only focused on the first two elements: Client Services and Product Management.  Their main responsibility is to the client.  The Product Owner role is expanded from that to include the additional three elements.  All of these elements are grafted together like the boysenberry was in order to make a stronger and more integrated role, which is truly focused on getting the best product to market.

The product owner moves from a 2D perspective focused mostly on client needs to a more global and 3D perspective.  They are capable of advocating for the client, encouraging and inspiring respect for their team, and truly pushing each to create a product that connects to the current landscape in a successful way.  The Product Owner must be able to work strategically and tactically, depending on the need of the moment.  The fact that the same person running the team is also communicating with the client significantly increases efficiency.

What does this mean when you ask us to solve one of your problems?  We are able to adapt to your needs and continue to push for the answers that will bring your ideas to life and solve some of your most difficult business issues.  Just like the hybrid boysenberry, we bring the knowledge of several independent work flows together under one individual so that you get a stronger and more integrated project.

We would love to talk to you more.  Stop by our office if you are in the area, or give us a call.  Let us know how we can utilize our process to meet your needs.

One the most rewarding things about telling a story that people want to hear is that, generally speaking, you get to tell your story a whole lot more. What attracted me to RevUnit in the first place was the freshness and uniqueness of its short, yet powerful story. Almost instantly, I knew I wanted to be a part of it. More than that, I was absolutely sure I wanted to lend a hand in crafting it.

In a much appreciated twist of fate, it’s a story that I now find myself telling quite often. Over the past few months, especially, I’ve spent a lot of time in conference rooms talking with folks about RevUnit—who we are, why we’re different, and what we do. However, it’s how we do it that distinguishes us from most.

When I tell people I work at a “product development shop”, typically what follows next is one of at least three different reactions: (1) Eyebrows raise circa Dwayne “The Rock” Johnson, (2) Eyes open wide, or (3) More often than not, a slumped, slouched posture instantly corrects itself. Simply put, people are interested.

Agile product development isn’t new. What we have done, however, is put our own spin on the methodology. This is the point where I’ll make a horribly choreographed—but still relevant—advertising analogy. To borrow a line from Chick-Fil-A, “We didn’t invent the chicken—just the chicken sandwich.” That is, we’ve crafted a product development recipe that works for our team and our clients.

RevUnit was built for serious product development. Naturally, it follows then that people come to us because they want to build things—specifically, digital products. When anyone—be that client, colleague, friend, cousin, uncle, or distant acquaintance who simply knows that I “build apps and stuff”—pitches me a product idea, I tend to make four assumptions right off the bat.

1) You can’t afford six-month timelines with little or no value.

This is more than an assumption; it should be a mindset. From the beginning of the build, you should expect to see tangible progress (user validated feedback or iterative prototypes) on a continuous basis. Agile pulls value forward in the product cycle, establishing a continuous feedback loop that is used to further define product requirements, test alternative hypotheses, and define product strategies. Smaller, more agile cross-functional teams speed up product cycles, remove inefficiencies, and allow you to maximize value.

2) You have an idea, but you really don’t know what you want to build.

You’re not supposed to have all the specifics defined immediately. That’s okay. Traditional processes fall short because they generally don’t account for the unknown. Business requirements and product timelines are all crafted under the assumption that a product is concretely defined from the start. Agile assumes that isn’t the case. Rather than defining what we absolutely need to build, we’re using the scientific method to prove out hypotheses (or what we think we should build) through user testing and analytics. These learnings lead to changes or pivots in product strategies that otherwise would not have been discovered.

3) You’re building a product so that people will use it.

When you build a product, you naturally expect that people will use it. There’s an inherent voice in each of our brains that says, “If I’m building something for someone to use, then that person will use it.” It sounds farfetched, but it’s a fundamental bias of most product teams. For that statement to be true, it requires that people actually find your product useful in the first place. The problem is that most traditional processes don’t put the product in the hand of the user until it is launched and out the door. By then, it’s too late. Agile product development seeks to eliminate as much “waste,” (what users find unnecessary), by continuously soliciting feedback from real users to incorporate back into the product itself.

4) You’re not thinking about what happens after launch.

Users today expect product teams to learn from their suggestions and behavior and make improvements over time. There’s no such thing as “set it and forget it” in product development. Because of its fluidity, agile product development encourages a continuous product lifecycle -one in which user feedback is constantly gathered, rigorously prioritized, and then injected back into the product. This process enables us to zero in on exactly what users want, maximize your investment, and remove inefficiencies and excess waste.

I’ve found these four assumptions to be fairly universal, and perhaps, the best explanation of why you should care about agile product development. When you venture out of digital marketing and into product development, the technical prowess required to execute increases exponentially. Product development dictates that we think, learn, and build in an entirely different way.

Though the who, what and why will continue to evolve as RevUnit grows, the how is a piece of the puzzle that is fundamental to everything we do and will continue to drive our growth as a company. We’ve been fortunate enough to craft a story that people want to hear as well as bring together a uniquely qualified team to execute projects in a way that is smarter, more flexible, and more efficient for our clients.

There’s a lot to like about agile product development that I didn’t cover here. If you simply want to know more—or want to become a part of our story—feel free to get in touch.

[email protected]

Content can be hard.

Master content writer Eugene Schwartz often spent an entire week on the first 50 words of a sales piece — the headline and the opening paragraph. While this might not be practical for the content you produce, it does illustrate the point that the content process isn't easy.

After working on some very big content projects involving the organization of over 10,000+ pieces of content (articles, images, video, and audio), I've seen the process for creating and organizing content at it's best and worst. I've worked to develop and organize a content process that fulfills the reason for creating content in the first place - to get the right message in front of the the right person at the right time.

This content process is called a content strategy. In the slide deck below you can walk through a presentation that I've given to industry experts, professionals, clients, and business students. The presentation outlines key elements of content strategy and RevUnit's unique take at marketing using our Build Small. Learn Fast. Iterate Often way of life.

Agile Content Strategy from Seth Waite

An Outline of My Presentation

1. DEVELOPING A CONTENT STRATEGY

2. WE ARE ALL CONSUMERS

Our expectations for digital are set by the brands we interact with. The internet is self-selecting which means that unlike the days of going to your town square and only being able to visit the stores and see the community presented in front of you, today the internet user can choose to interact with whatever they want to. We all choose to consume whatever we want to whether it's a product or content online. We go to a search engine and type in keywords to find what we want to consume.

If your experience (content) in this process doesn’t measure up, it’s going to hurt your brand. Research suggests that a sub-par user experience with a brand results in 47% of site visitors having a less positive perception of the company… and a third went on to tell others about it.

3. WE’RE LESS TOLERANT

As consumers with more than 2 decades of internet experience we expect more of our digital experience. When users have a less than positive experience online which can be slow loading web pages, mobile apps that don't work, or content that isn't accurate or useful… 78% go to competitor site. That number is a killer for anyone that spends a lot of time and money on creating content.

Even more harmful is the fact that 88% are less likely to return and 38% go to a competitor and never return. The good news is that if you are successful in creating content that provides a positive experience you have abundant opportunities to increase your user base.

4. YOUR NEW COMPETITION

We compete with content creation in a variety of places. Some of them are platforms on the web, mobile phones, or in digital form in a physical location. Competitors are using these platforms to create enormous amounts of content.

5. CONTENT IS… WHAT PEOPLE WANT, WHAT PEOPLE SHARE, and WHY PEOPLE ACT

Content is everywhere online. It is the substance of the internet and users know the difference between good content and bad content. Companies of all sizes need to realize that great content is required for success in digital.

6. WE ALL MAKE CONTENT

It's easy to see that today more than ever we are not all just consuming content but we are also the producers of content. We use social media and dozens of other sites to create content every day.

7. SO WHAT IS CONTENT STRATEGY

Planning

Production

Publication

Promotion

8. AGILE CONTENT

In traditional content creation significant effort is put into the content production and publication process. The entire process is completed and the content is published. Then the you wait to see if it will work. Is it the right message, to the right people, in the right place, at the right time?

At RevUnit we use an agile method of content strategy. Using our Build Small. Learn Fast. Iterate Often. mentality we make frequent, planned content strategy cycles which allow us to go through small cycles of content to make sure it meets the purpose of its production. Then based on what we learn we make adjustments. Then we build and publish more content and start the cycle again. Our content strategy process enables us to prioritize feedback and respond immediately to what users are saying. This connectivity with users builds loyalty and drives continued engagement with the content.

9. CONTENT

Building small requires rigorous prioritization of content opportunities based on existing user insights and business objectives Our aim is to learn from real users on a subset of content and let those insights inform the future allocation of resources. To prioritize we look for content that has the biggest size of success (ROI) with the smallest level of effort.

10. PLANNING

Planning is about understanding your objectives and aligning them with the intent of your audience. By focusing on the intent of a user first, you are sure to meet the needs of the user and address what is most important to their self-selected interests.

11. CONTENT PRODUCTION

Creating great content is lots of hard, rigorous work and there are no shortcuts to doing it right. You have to know who you are going to have produce your content, where it is going to live, and how it will be displayed. For this reason your content strategy product should understand the technologies and platforms your content will be published using. All platforms and technologies will produce differing challenges and advantages in how you create your content for publication. Understanding your content's constraints will help you the most at preventing significant limitations in the publication and promotion of your content.

12. PLANNED PUBLICATION

Though content roadmaps are critical, room must be made for the learnings gained from users. Your content strategy should be a living, breathing process which allows you to listen and learn from how users are interacting (or not interacting) with your content. If you don't take the time to listen and learn, you are just producing content for yourself.

13. PROMOTION

Content isn’t valuable to you or the audience you worked hard to create it for if nobody knows you created it. Great content is easier to promote, but it wont share itself. The boxes on the right and left, Upkeep and Search, are less sexy than straight promotion but do require significant thought and effort to ensure your content is successful.

14. CONTENT STRATEGY

Great content requires strategy:

Planning

Production

Publication

Promotion

15. If you love content or need help, feel free to reach out to me at:

Email:   [email protected]

The design community–and I’m not just talking digital here–loves to gloat about how much better we are than everyone else. We try to convince the world, and ourselves, that what we design today will be found in the graphic design textbooks of tomorrow–exclusively revised for our work, of course. Our magically delicious ‘design sauce’ won’t just make projects look great; it will revolutionize design itself, while simultaneously ending world hunger.

We use our arsenal of buzzwords and rhetoric to convince clients how that last designer they hired didn’t really have the know-how necessary to achieve the results they were entitled to. We hang our grossly overpriced and overrated awards around us like armor to deflect those “dull-witted” arguments from others and use our expert-experienced-expertise to beat the unmotivated masses into super-buying consumers through our irresistible design medicine.

I’m convinced that it is one of the most ego-driven professions out there. Heck, I’d even gloat about us having bigger egos than programmers if I had the chance (see The Ten Commandments of Egoless Programming). From agency to freelancers, when clients need design work done we designers are always talking about how we’re the next hotshots on the block who know it all–which in turn shows that we really know nothing.

A mindset of pride and arrogance doesn’t help us do what we’re supposed to do: solve problems and add value. At best, this mindset masks problems. At worst, it creates unrealistic expectations that let both the client and the consumer down. Starting a project requires that we take the awards and glitter away. We must set aside our own opinions in order to best meet the needs of those involved in the project.

Design is more than the designer, and even more than the finished product. One of my favorite graphic designers was Paul Rand. I wasn’t drawn to him so much for his work as I was for his thinking. Paul believed that “design is much more than simply to assemble, to order, or even to edit; it is to add value and meaning, to illuminate, to simplify, to clarify, to modify, to dignify, to dramatize, to persuade, and perhaps even to amuse...” Does our design matter if we like it, but the client that requested it doesn’t? Does it matter if the client likes it, but the consumer doesn’t see the value? And does any of that matter if our developers can’t build it or we don’t have the budget to make it happen? Design only matters when it adds value to the brand, enriches the life of the consumer, and can actually be built.

Having taught at an introductory course at a university for the past 2 years, I found that the best way to convey the role of a designer is to think of them as a mediator. Designers find themselves in a unique role within businesses, which may be part of the reason why we get such big heads. It is our utmost responsibility to judge and weigh consumer wants, client requests, project manager requirements, and developer needs with our own experience and creativity. Being a designer is a balancing act. Each of us has our own knowledge, experience, and expertise that we draw from. These qualities we offer are good and of value but at the right time and with careful consideration. Not everything we make will be a masterpiece. Actually, most of what we make won’t be–at least not to us. But that’s just it. What we want and what we think isn’t all that matters and it isn’t what makes a project great. To quote Paul Rand again, “if a company is second rate, the logo will eventually be perceived as second rate.” There’s a lot more at play than our designs. We need to take a larger role in helping shape the values–not just the perception of those values–of the brands we work with.

When establishing a company’s brand, I begin by asking what that company values. “Quality” and “Integrity” are always the first words on the list, but when actually faced with a circumstance that requires those values, many of those companies buckle and compromise under pressure. It’s not because they want to. Oftentimes they don’t see their decisions as compromising, or don’t have processes in place that help secure those values. We can’t just label a product “quality” and people believe it. Quality and integrity are hard things to come by. They take time and require sacrificing what we want for what we really need.

Here at RevUnit we have a saying, “Build Small, Learn Fast, Iterate Often.” It’s the cornerstone to who we are. We don’t claim to have a magic prescription that guarantees success. What we do have, though, is a process that helps guide our clients down a path that increases their chance of success and curbs the cost of failure. Instead of building a fully loaded, galactic-edition piece of software that flops on launch and bankrupts our clients, we choose to start with the minimum viable product–the bare essentials to accomplish the task at hand–and methodically apply learnings from user testing as we build and iterate. Instead of requiring our clients to blindly trust our opinions and experience, we provide tested proof on their own projects.  

Designers must have a mindset like RevUnit: humility rather than arrogance. It’s important for us to question everything–even ourselves. Questioning doesn’t come from a disregard for authority or selfish skepticism, but out of a curious respect for the truth. We should always be willing to put aside our ambitions in favor of doing what is right.

When I was home sick from school as a kid, one of my favorite movies to watch was Field of Dreams. At a great turning point in the movie, Kevin Costner hears a voice that whispers, “If you build it, they will come”.  While this was true for Mr. Costner and his long lost father, I have found it to be utterly false in every other aspect of life. Especially digital.

And for that reason, we are pleased to announce the acquisition of Smash Metrics from Las Vegas, Nevada. When we “build it”, the Smash Metrics group ensures people “will come”. This new team plugs an important skills gap for us by adding sound digital marketing capabilities to our product development focus at RevUnit.

If I’m being honest, we’ve long been hesitant to add marketing as a capability at RevUnit. In fact, we don’t even really like the word. So many marketers seem to bring a “tagline” led approach and fuzzy ROI math that just isn’t applicable in digital. What we love most about Smash Metrics is their hyper focus on data. They view digital marketing as a science and have proven methods of achieving success through rigorous testing and campaign optimization. Truly, they align with our vision of “Build Small, Learn Fast, Iterate Often”.

Though small, this new team is mighty. We welcome Seth Waite (Sr. Strategist & Product Owner), Alex Diebel (Strategist & Product Owner) and Joey Montano (Strategist) to the RevUnit team and look forward to all they will contribute in the years to come. They are ushering in new capabilities at RevUnit such as SEO strategy, content marketing, analytics, media, and eCommerce strategy.

We are strong believers in the agile method of software development. We break down key features into user stories, do sprint planning, track velocity, unit and integration testing; all that good stuff. But we've had a few key pillars of agile development missing for a while and we recently rectified that. RevUnit's process now fully incorporates continuous integration and continuous deployment. This enables us to automate more of our process which frees us up to focus on the important things -- like implementing and shipping features!

Automate all the things!

Automating your workflow is vital for a streamlined development process. There are so many small tasks that a developer has to do in addition to their core duties that it can really drain not only the time the developer has but also their focus on the more important tasks at hand. With so much to do just to enable the ability to do the things we have to do, how do we get anything done at all?

"Progress isn't made by early risers. It's made by lazy men trying to find easier ways to do something." - Robert A. Heinlein

All development organizations should have the mindset of automating their workflow but it is especially important for smaller start ups. You're not going to have a QA team or a deployment team. You have one team to do all the things. There are many ways to automate your workflow. We even have a chat bot in our company chatroom that can interface with our GitHub repositories, our project planning system, our production error reporting system, as well as many other integrated systems we use for our planning and development workflow end to end. It even has automated photos of kitties or animated gifs for when we are feeling down.

Specifically for this post, I'll talk about how we automated our integration testing and deployment using Continuous Integration and Continuous Deployment.

What Is Continuous Integration?

Continuous Integration is a software development practice where members of a team integrate their work frequently. This integration is trigged by every push of new commits to GitHub. Each time a developer pushes new code to GitHub our CI system clone's that branch and runs all of the entire unit and integration test suite.

This is all done automatically on a post-receive hook on GitHub without any manual intervention from a developer. This enables the team to rapidly find integration errors or regression failures in the test suite. This tightens the feedback loop and not only enables more defect free code, but greatly speeds up our process.

Developer A may have a completely green (passing) test suite on their local machine at the same time that Developer B also has a completely green test suite on their machine. Without this continuous integration process, the tests from those separate developers would not be run together (integration testing) until further down the line; and even then by some manual intervention by a developer.

The instance where CI really shines is in rapidly exposing regression failures. Without a thorough test suite and CI, a feature that was complete in week 2 of development and was destroyed by a feature that was completed in week 12 of development will never be exposed until the very end in a formal QA process. Obviously that is less than ideal. We need to know about defects immediately or it could really derail the speed and fluidity of our process and our ability to quickly deliver results to a client. This is especially important for defects in features that we already completed and tested thoroughly.

What Is Continuous Deployment?

So we've automated our integration testing and building, what's the final step? Deployment. This step of the process can take the longest time depending on the complexity of your application. I've even worked in a large corporate environment wherein if you wanted a deployment to the staging servers you had to contact a deployment team which could take up to a week to finally get deployed. That's crazy!

Traditionally you plan development which leads into testing and QA which ultimately leads into a planned deployment. You need this planned/tiered (WATERFALL!) approach to development and release when you don't have CI or even further don't have any unit or integration tests. You don't want to deploy an app that you're not positive is working 100% as it should. Someone call the QA team and tell them we're ready! Ain't nobody got time for that.

At this point we've ensured the integrity of our application through ongoing continuous integration. So what is stopping us from automating the final step? Continuous Deployment (sometimes referred to as Continuous Delivery) fills in this gap.

Continuous Deployment (CD) is a software development practice that triggers an automated deployment of the application after passing all tests and builds in the continuous integration process. This means that as soon as a build is successful on the staging branch, it is automatically deployed to the staging application. Enabling the client to see the most up-to-date feature complete code at any given time. This should happen several times a day. You can take it even further to automate your deployments to production! Once a feature has gone through local unit testing, code review in a pull request, and multiple integration builds through CI, you can push it directly to your production servers giving your users immediate benefit rather than waiting for weekly or biweekly planned and scheduled deployments. Your calendar shouldn't have anything to do with shipping features to your users. Ship it early and ship it often.

Your calendar shouldn't have anything to do with shipping features to your users.

GitHub is fantastic at this and reported that their busiest day yet (as of a blog post in 2012 so I bet they've blown past this by now) was on 23 August 2012 with 563 builds and 175 deploys. [blog post by GitHub] That's 175 deployments to production in a single day on an extremely active application with millions of concurrent users worldwide! No "Under Maintenance" pages. No scheduled outages or deployments. Just ship, ship, ship.

Why Is All Of This Important?

As small teams that seem to always be increasing the requirements and expectations, we have to find ways to increase our speed while not decreasing our quality. A tough task. Just not decreasing the quality and maintaining the status quo almost isn't even an option either. We need to be increasing speed and increasing quality.

How is that even possible? Delegate work to the machines.

Using a rigid and well thought out process for your development can help reduce unknowns which will decrease defects, improve overall quality of your codebase, and enable you to rapidly iterate and deliver to your users. Automating that workflow will speed it up even further. It will also turn your development process from a passive process to an active process. Let the process tell you if things are working or breaking. This allows issues or roadblocks to bubble up to the top sooner and takes the responsibility off a single person to remember to accomplish many separate small tasks.

We have the technology.

Make life easier for yourself and your team at the same time as delivering better products to your users! It is possible.

Our Workflow

We use GitHub for our source control and Travis CI as our hosted continuous integration system. HipChat keeps us connected and aware of action happening within our system and workflow. We also use a modified form of git flow for our branching strategy.

Here is a quick and dirty overview:

* Master branch is the latest production release.

* Staging branch is the latest feature complete code that has been deployed to the staging application servers and not deployed to production yet.

* A feature branch is branched off of the staging branch and worked on until it is feature complete with accompanying unit and integration tests that verify functionality.

After a developer has finished the feature in their private feature branch, they initiate a Pull Request on GitHub to merge their feature branch back into the staging branch.

Travis CI captures the pushes to GitHub and the initiation of a Pull Request and runs the tests on the branch. With Travis CI's great GitHub integration, we can see right there on the Pull Request view whether or not the tests are passing or failing.

If tests are passing, we do a team wide code review on GitHub by commenting inline on all of the code that will be committed to the staging branch. We cycle through these comments and revisions until everything is good to go and we're ready to merge into the staging branch.

Throughout this entire process, pushes to GitHub, comments on code for the code review, passing or failing builds on Travis CI, and every other action related to our code/application/process is pushed to the chatroom in HipChat related to that specific project. Everyone is always up-to-date on what is happening with the project and there are no surprises.

Once the feature branch has passed a code review, has passing tests in CI and has been acceptance tested and accepted by the product owner, we merge it back into staging which then fires off another cycle of integration testing with our CI system.

Once this final build and test cycle completes with a passing status, Travis CI initiates and automatic deploy of the application to our staging environments.

If it is a Rails application, it kicks it off to our staging servers hosted on Heroku and notifies the applicable project room in HipChat of a successful build and Heroku deploy. Enabling the clients to see the latest feature complete build of their application on the web immediately after the feature has been completed.

If it is an iOS or Android application, it will build a binary and automatically deploy to TestFlight and send emails to all of the users on the beta-testing distribution list for that application. Enabling them to download the latest successful build immediately.

It's really a fantastic process!

As you can see, there are many checks for quality and functionality from the very beginning of the process all the way to the end. As well as backward/redundant checks to be sure everything that once was still is. And while it seems like a lot of steps, it is all automated! A great process should get out of your way and let you do your work. 

It's Been A Long Journey

We are really excited about this process and it really enables us to stand by our commitment to delivering quality code to our clients and their users. This process executed well almost completely removes the need for a QA period prior to production release which cuts time and cost for our clients.

Our development process is really what sets us apart from our competitors in the region and we're always trying to improve it. If you have a similar process or have any questions or comments, leave us some comments below and we'd love to talk to you about it.

Ways I see to improve it in the future:

* I am going to develop some dashboards that will always be displayed on a large tv in the office. So we can always see at a glance if a project's builds are failing. Or alternately, look up and see green across the board and know we are kicking ass at our job. :) 

* We use Hubot by GitHub as our chat bot and we'll be building more Hubot scripts to further automate our workflow.

Notes:

* Of course I didn't invent the term "Automate all the things!" so credit to whoever that person is.

* Martin Fowler's original essay on Continuous Integration: http://www.martinfowler.com/articles/continuousIntegration.html

RevUnit's engineering team is excited to welcome new developer and singing extraordinaire Joel Doyle!

Joel's developer origin story starts as a full-time rock 'n roller in Little Rock where he played guitar and was the lead singer for a popular band. He supported his rock and roll lifestyle on his path to becoming like his idol David Bowie like any good hipster would; by working at a local pizzeria and brewery. After it started to look like he might not be the next Ziggy Stardust, he went back to school at University of Central Arkansas in Conway, Arkansas, where he received a Bachelor of Science in Computer Science. We're not his first tech startup though. He moved from being an intern during school to a full-time developer at PrivacyStar in Conway after his graduation and has spent almost the past two years there working on PrivacyStar's mobile applications. 

His background is in Javascript web applications, but since we're a polyglot team of code assassins here at RevUnit, he'll be joining us to do pretty much anything required to get the job done. Everything from web applications with Ruby on Rails or single page Javascript applications with Backbone or Ember.js to iOS and Android Apps. 

When he's not working on code he loves to fly his (ridiculously expensive) FPV remote control plane (FVP Lab), riding mopeds, or spending time with his girlfriend Brittany Wheeler who is a manager at ZAZA's Pizza Company in Conway. 

His superhuman abilities include: 

- Being able to tell if an actor in an American movie is actually an Aussie or a Kiwi.

- Dancing like there's no tomorrow.

- An extremely high vocal range. Look out Geddy Lee.

Yesterday I found this great post on being a Senior Engineer and one of the best portions, of what was an outstanding albeit very long post that you should also read, was this list of Ten Commandments of Egoless Programming. The writer was making the case that there's a lot more to being a Senior Engineer than just knowing all of the APIs by memory. He introduces the term "Mature Engineer" rather than Senior Engineer; meaning there are a lot of interpersonal, communication, and intangible skills that you gather only through a long stream of real world experience managing projects and people rather than expertise on a language or codebase. 

This list is so spot-on that it should be required reading for all developing engineers and should probably even be posted on the wall in the office. They are great milestones to follow on the road to mastery as an engineer. 

The Ten Commandments of Egoless Programming

1. Understand and accept that you will make mistakes.

The point is to find them early, before they make it into production. Fortunately, except for the few of us developing rocket guidance software at JPL, mistakes are rarely fatal in our industry. We can, and should, learn, laugh, and move on.

2. You are not your code. 

Remember that the entire point of a review is to find problems, and problems will be found. Don’t take it personally when one is uncovered. 

3. No matter how much “karate” you know, someone else will always know more. 

Such an individual can teach you some new moves if you ask. Seek and accept input from others, especially when you think it’s not needed.

4. Don’t rewrite code without consultation. 

There’s a fine line between “fixing code” and “rewriting code.” Know the difference, and pursue stylistic changes within the framework of a code review, not as a lone enforcer.

5. Treat people who know less than you with respect, deference, and patience. 

Non-technical people who deal with developers on a regular basis almost universally hold the opinion that we are prima donnas at best and crybabies at worst. Don’t reinforce this stereotype with anger and impatience.

6. The only constant in the world is change. 

Be open to it and accept it with a smile. Look at each change to your requirements, platform, or tool as a new challenge, rather than some serious inconvenience to be fought.

7. The only true authority stems from knowledge, not from position. 

Knowledge engenders authority, and authority engenders respect so if you want respect in an egoless environment, cultivate knowledge.

8. Fight for what you believe, but gracefully accept defeat. 

Understand that sometimes your ideas will be overruled. Even if you are right, don’t take revenge or say “I told you so.” Never make your dearly departed idea a martyr or rallying cry.

9. Don’t be “the coder in the corner.” 

Don’t be the person in the dark office emerging only for soda. The coder in the corner is out of sight, out of touch, and out of control. This person has no voice in an open, collaborative environment. Get involved in conversations, and be a participant in your office community.

10. Critique code instead of people – be kind to the coder, not to the code. 

As much as possible, make all of your comments positive and oriented to improving the code. Relate comments to local standards, program specs, increased performance, etc.

What is your experience with these ideals? Do you live and die by any specific one? Are any specific ones challenging for you? Let's discuss in the comments!

As a founder, you learn quickly that everyone wants you to explain your company in 20 seconds or less. Very early on in our company we coined a phrase that has stuck with us ever since. Build Small, Learn Fast, Iterate Often. At times we’ve adhered to this less than we should have, but it remains a guiding star, a competitive differentiator and an ideal for how we approach our work here at RevUnit.

Build Small

By building small we release faster. Releasing faster allows us to subject the product to real user feedback much earlier in the process. The fact is that no amount of strategy, planning and forethought makes a product infallible. We always learn more when real users give us feedback. When that feedback is obtained earlier we have more time and budget to course correct. We’re less invested in our ideas and more open to what the user has to say.

Learn Fast

We like to say that learning is about listening. And listening is about tooling. We often find ourselves talking clients out of features and in to listening tools. Tools like UserVoice, Google Analytics, Crittercism and the App Store help us understand what our users want and ultimately drive the product roadmap for future phases. We can’t be so tied to our own ideas that we’re not willing to consistently inject user feedback into our roadmap.

Iterate Often

There’s no such thing as “set it and forget it” in technology. We try to be as transparent with our clients as possible on this. Anything we build has to be supported. The consumer expectation today is that you’re always improving, always adding features and fixing bugs. This is led by the giants of our industry like Google with their “constant beta” approach. If there’s no funding to iterate on a project then it needs to be broken into smaller chunks or dropped all together.

At RevUnit, one of the many decisions we help our clients navigate when taking on new projects is whether or not to buy an existing technology or build from scratch. As with most technology questions, the answer typically is “It depends.”

What follows are a few of the questions we work through in making the decision:

Is this feature or component core to your business?

If something is core to your business, you will probably want more control and be unwilling to compromise on features. For example, if you are building an online dating site, you should probably own and have complete control over the code and algorithms to match potential partners. In that case, it probably makes sense to build that particular component. However, if you are a web-based startup and your app needs to send emails, it’s probably not worth setting up and maintaining your own mail servers. Just pay someone a few bucks a month and consider it a solved problem.

How important is it for you to differentiate?

This is somewhat related to the previous point, but if you are looking to truly set yourself apart from your competitors in a particular area, building makes a lot of sense. Just remember that if you can purchase an off-the-shelf solution and have it live in a month, so can your competitors.

Does it do everything you want it to do?

Prior to vendor evaluation, have you defined what features need to be present to solve the problem at hand? If not, you run the risk of becoming enamored with a solution and compromising on what you originally set out to accomplish. If you have documented those features, make sure that the potential solution can meet all of those needs. If it doesn’t, you’ll need to decide if the potential cost savings is worth losing a desired feature.

Does it do too much?

A mistake that a lot of folks make is choosing a solution that has a ton of options that look great on a feature matrix spreadsheet. However, when it comes down to it, only a small amount of those features are really relevant. This can lead to longer implementation time as you struggle to turn off or hide a number of features you don’t want. A cluttered and confusing interface can lead to lack of adoption just as easily as missing features.

Does the vendor’s long term roadmap align with yours?

Can the vendor articulate where they want to go with their product? Is that roadmap heading the same direction as yours? If your product is successful, you’ll have a long-term relationship with this particular vendor. You want to ensure that they’ll still be around and still be focused on helping you grow your business a few years from now. Things to watch for here are the age of the company, whether or not this is a side-project or their core offering and whether or not they are on the cutting edge of technology in their space.

We love building new products for our clients, but the part that we love the most is solving the unique business problems at hand. If someone else has a great existing solution that helps us solve those problems more quickly, we’ll recommend it.

Git provides a very valuable feature that many developers seem to either overlook or blatantly not care about; it enables you to add distinct sections to a commit message. Specifically, it allows you to add a short summary for the commit and a long and detailed body.

A great commit message:

Capitalized, short (50 chars or less) summary More detailed explanatory text, if necessary. Wrap it to about 72 characters or so. In some contexts, the first line is treated as the subject of an email and the rest of the text as the body. The blank line separating the summary from the body is critical (unless you omit the body entirely); tools like rebase can get confused if you run the two together. Write your commit message in the imperative: "Fix bug" and not "Fixed bug" or "Fixes bug." This convention matches up with commit messages generated by commands like git merge and git revert. Further paragraphs come after blank lines. - Bullet points are okay, too - Typically a hyphen or asterisk is used for the bullet, preceded by a single space, with blank lines in between, but conventions vary here - Use a hanging indent

Key points of a well formed commit message:

Must have a summary line

Summary line must be 50 characters or less

Should have a well thought out and meaningful description

No line in the description should be over 72 characters long

Format breakdown:

First line is summary

Second line is empty

Third line starts the in-depth description

Be sure to write your summary in the present tense imperative. For example, instead of "Adds new copy to homepage" use "Add new copy to homepage" or instead of "Fixes bug #234234" use "Fix bug #234234". This follows the convention that git itself uses. Have you ever noticed when you merge a branch the commit message is "Merge [branch]" and not "Merges [branch]" or "Merged [branch]"?

Why?

A lot of this info comes from a great blog post by Tim Pope in 2008. I didn’t make the rules I just follow them.™ Various git commands pull the summary automatically and will just truncate your commit message if it is too long. This makes scanning the commit history very cumbersome and annoying. Commit summaries allow you to quickly convey the full intent of the commit in a single and succinct line. Think of it like the subject line of an email. Yesterday I was needing a break from normal work and decided to work on some git hooks that would make me follow these rules. Git provides several hooks into git events for you to do some pre-defined action prior to or immediately after a commit.

[master][~/dev] ls .git/hooks applypatch-msg.sample post-update.sample pre-commit.sample prepare-commit-msg.sample commit-msg.sample pre-applypatch.sample pre-rebase.sample update.sample

I want to validate the commit message after the user creates the message but prior to it being committed to the repository. The specific hook I need for this is the `commit-msg` hook. If you remove the `.sample` from these files git will run them at their appropriate times. They are shell scripts and I could have written my message checker in a shell script like bash but I’m really not good at awk and sed and all that crazy shell scripting voodoo. So I just use the commit-msg shell script to call my own python script.

#!/bin/sh exec < /dev/tty .git/hooks/validate-commit.py $1

What I want this script to do:

Verify I have a summary line on my commit

Verify the summary line is not over 50 characters

Verify no line is over 72 characters

If there are any errors, reject my commit and ask me to reformat

If I choose to reformat my commit, bring me back into the commit editor and show me what exactly was wrong with my commit in comments on the commit message

After a few beers and some tinkering I ended up with this messy bit of python code:

#!/usr/bin/python import sys, os from subprocess import call if os.environ.get('EDITOR') != 'none': editor = os.environ['EDITOR'] else: editor = "vim" message_file = sys.argv[1] def check_format_rules(lineno, line): real_lineno = lineno + 1 if lineno == 0: if len(line) > 50: return "Error %d: First line should be less than 50 characters " \ "in length." % (real_lineno) if lineno == 1: if line: return "Error %d: Second line should be empty." % (real_lineno) if not line.startswith('#'): if len(line) > 72: return "Error %d: No line should be over 72 characters long." % ( real_lineno) return False while True: commit_msg = list() errors = list() with open(message_file) as commit_fd: for lineno, line in enumerate(commit_fd): stripped_line = line.strip() commit_msg.append(line) e = check_format_rules(lineno, stripped_line) if e: errors.append(e) if errors: with open(message_file, 'w') as commit_fd: commit_fd.write('%s\n' % '# GIT COMMIT MESSAGE FORMAT ERRORS:') for error in errors: commit_fd.write('# %s\n' % (error,)) for line in commit_msg: commit_fd.write(line) re_edit = raw_input('Invalid git commit message format. Press y to edit and n to cancel the commit. [y/n]') if re_edit.lower() in ('n','no'): sys.exit(1) call('%s %s' % (editor, message_file), shell=True) continue break

Now if I try to commit a badly formed commit message like this:

Curabitur blandit tempus porttitor. Nullam quis risus eget urna mollis ornare vel eu leo. Nullam id dolor id nibh ultricies vehicula ut id elit. Cras mattis consectetur purus sit amet fermentum. Maecenas faucibus mollis interdum. Etiam porta sem malesuada magna mollis euismod. Nulla vitae elit libero, a pharetra augue. Donec ullamcorper nulla non metus auctor fringilla. Praesent commodo cursus magna, vel scelerisque nisl consectetur et. Sed posuere consectetur est at lobortis. Maecenas sed diam eget risus varius blandit sit amet non magna. # Please enter the commit message for your changes. Lines starting # with '#' will be ignored, and an empty message aborts the commit. # On branch master # Changes to be committed: # (use "git reset HEAD ..." to unstage) # #> new file: 31234 # diff --git a/31234 b/31234 new file mode 100644 index 0000000..e69de29

It will kick me back to the shell and prompt me with this message:

"Invalid git commit message format. Press y to edit and n to cancel the commit. [y/n]"

Once you press "y" to edit your commit it will send you back to your commit editor and allow you to fix the bad formatting and even tell you which lines were incorrect and why!

Curabitur blandit tempus porttitor. Nullam quis risus eget urna mollis ornare vel eu leo. Nullam id dolor id nibh ultricies vehicula ut id elit. Cras mattis consectetur purus sit amet fermentum. Maecenas faucibus mollis interdum. Etiam porta sem malesuada magna mollis euismod. Nulla vitae elit libero, a pharetra augue. Donec ullamcorper nulla non metus auctor fringilla. Praesent commodo cursus magna, vel scelerisque nisl consectetur et. Sed posuere consectetur est at lobortis. Maecenas sed diam eget risus varius blandit sit amet non magna. # GIT COMMIT MESSAGE FORMAT ERRORS: # Error 1: First line should be less than 50 characters in length. # Error 2: Second line should be empty. # Error 7: No line should be over 72 characters long. # Please enter the commit message for your changes. Lines starting # with '#' will be ignored, and an empty message aborts the commit. # On branch master # Changes to be committed: # (use "git reset HEAD ..." to unstage) # #> new file: 1234098 # diff --git a/1234098 b/1234098 new file mode 100644 index 0000000..e69de29

This tells us that we have errors on line 1, 2 and 7 of our commit. I think I've accomplished all my goals! Now I’ll be forced to follow good practices on my commit messages. Sometimes you need a little push to do what's right! I actually wrote this intially in Ruby, if you know me you know I am definitely not a python programmer, but had some problems I couldn’t figure out with forking subprocesses for the editor after a second commit rejection. I needed it to stay in the error loop and check the message again but if you rejected your commit and then tried to use the exact same message with the errors again, it would succeed and commit to the repository. Being a little side project I didn't plan on spending more than a couple hours on I had to abandon it and move on to an alternate method. Someday soon I’ll dig into that more but for now this python script will certainly do!

Now go create some git-hooks to improve and automate your own workflow!

Do you follow any guidelines on commit message format?

And welcome to the RevUnit blog. This last week we finally decided to get this started. As anyone who's been in our shoes can attest, launching a new company from the ground up can be a daunting task and you just don't have time for all the things you'd like to be doing… like blogging. I'm sure prioritization of tasks when building a new company will be a future post, so more on that later.

RevUnit… who dat?

My partner, Michael Paladino, and I started RevUnit a little over 8 months ago. It was founded on this one idea… that effective marketing is less about what you say and more about what you do — because if you do it well, everyone else will say it for you.

With the democratization of brand perception, the power has shifted from brand voice to consumer voice and any effort to tell customers we're great at something falls flat unless we are truly great at that thing. This motivated us to build a different kind of agency at RevUnit. One that is more focused on great execution than taglines and more dedicated to the user than our own ideas. In short, instead of focusing on how our clients are portrayed to their customers, we build technology that makes their customer experience exceptional. We find this improves brand sentiment more than anything we can possibly say.

So as an industry we need to shift our focus. We see a wealth of agencies who can tell clients what to talk about, but a serious shortage of those who can build experiences worth talking about. After all, having the customer tell our story for us has always been the higher form of marketing.

Here's how we're different

When we decided to focus on building exceptional customer experiences on digital and mobile it changed everything for us. We built our teams smaller, we made our process leaner and focused a LOT on our tooling. It's been about shortening lines of communication and advocating for our users.

We've become less attached to our own wisdom and more interested in what users are saying. This means we create more touchpoints for user feedback with sketching, wireframing and prototyping. Our goal is to not spend a single dollar of our client's money on features that no one wants. By prioritizing the work into smaller chunks and validating with users along the way, we achieve products that deliver a much higher ROI for our clients and a more satisfactory experience for the customer.

What to expect here

We hope you'll check in with us often. Our team is excited to contribute with learnings and opinions across a wide variety of topics. I'm sure there will be ranting, probably some shameless self-promoting and maybe even a few confessions from us tech adrenaline junkies, but our main goal is to contribute and to play our part in the conversation that moves our industry forward. We invite you to join us. Your thoughts, comments and push back are welcome here. Shoot holes in it.

Sincerely,

Joe Saumweber, Co-Founder & CEO