Lost your Mockups key?
Retrieve Your License
Log In to myBalsamiq
Already have a monthly subscription for our cloud-based web app?
Log In to myBalsamiq
This post is part of a series about our VERY FEW company policies. Read this intro post for some context.
At Balsamiq, we don't have deadlines. Ever.
It seems so natural to me, but I sometimes get reminded of how uncommon this is for software companies.
It may be because we're small and it might change in the future, but the few times I've tried to set a deadline so far, things quickly started to go south.
We started stressing out, not enjoying our work as much and, ultimately, not doing our best work.
Since we're bootstrapped, profitable and independent, our only pressure comes from our customers, and from our own urge to do great stuff (we don't really look at what the competition is doing, so they're not really a factor, at least for now).
I also value work/life balance immensely, and believe employee burnout is a one of the worst things that can happen to a small business.
So ever since I started, I have been talking internally about pace.
The metaphor I use is about driving a stick-shift car: sometimes we go in 4th gear, sometimes in 5th, but sometimes we have to go in 2nd or 1st, it's just the way it is.
In general, we should strive to hum along in 4th gear. If 5th gear happens, that's awesome. If 3rd gear happens, that's fine too. If it's August and the whole dev team is on holiday at the same time and we spend a week in 1st gear, so be it. It's just temporary.
Being in 5th gear all the time is dangerous, and being stuck on the highway in 2nd gear sucks.
Another metaphor is of a huge holiday meal: it's all good, and there's lots and lots of it. If you eat too much at first, you won't have room for the rest. Slow down a bit and save some for tomorrow and the next day!
We could hire more developers or outside contractors to build our features faster, but that would mean that
"Founders at Work" taught me that first-to-market is totally overrated. In fact, most successful companies were 2nd or 3rd to their market, learning from their precursor's mistakes. Mockups wasn't the first wireframing tool out there.
What do you think? Am I being naive? Why do people set deadlines? I'm genuinely curious about it. Let's discuss in the comments! 🙂
Hope this helps,
Peldi for the Balsamiq team
Get the Inside Scoop
We'll send you just one email a month and share a ton of information that you'll get before everyone else. More info about the newsletter here.
We'll never share your email address or spam you.
Peldi it has been a joy getting to talk with you more and more each day. You and Val are amazing, and this approach is one of those reasons why.
For us at FRA PlanTools we live off of deadlines. Primarily because we’re doing “Work for Hire” for Fortune 400 companies, so we have to operate at a high pace speed, but that doesn’t mean we don’t put in buffers, we know we can’t operate in 5th/6th gear all the time. When it comes to our SaaS product, we operate at our own pace, but we do set goals.
An example of a goal would be: I want to finalize this feature by March 1 and have it tested and deployed by March 15 if there is no errors present.
You added a great read to my ☕️ today!
This is awesome. Brilliant, as usual Peldi. Living in 4th gear. Looking forward to many more great conversations.
Pingback: 10 lầm tưởng phổ biến về Start-up | Con Phố Nhỏ
Pingback: 10 Myths about Startups : EMUKUPA
Pingback: 10 Myths about Startups
This is exactly how I would run my company. As long as you have the culture in place and people doing what they love you’ll have “deadlines” met without having to spell them out. I know when I am working on something I enjoy, sometimes I wake up earlier or stay even later just to work on it because it’s something I look forward to.
Also, your comments on first-to-market hit home with my line of thinking. I actually wrote in my private business journal -“In business everyone wants to be the first, but first is not always good, because aspiring competitors learn your mistakes and improve upon it.”
I love this policy… and it captures things so well. So many bad decisions are made because of deadlines.
Your whole ethos reminds me a little of the “slow food” movement that I enjoyed so much last time I visited Italy. Life is to be enjoyed and appreciated including the business of doing our work well and enjoying sustenance.
I am going to do this at my company and see how it goes. I think its brilliant idea
Pingback: 2012 Year in Review | lucisferre.net
In an environment like Balsamiq, and any environment I would like to move into in future, you have several factors that influence your productivity and efficiency. When you hire the right people they have an innate drive to excel and perform. The more important task from a management perspective becomes how to harness and focus this ‘force’ to achieve the necessary momentum/pace in the right direction. Plan your execution in terms of milestones and functionality, but stay away from deadlines, IMHO they are the product of unproductive career managers.
In larger corporations you can address deadlines by having your sales ‘force’ not selling into the future. Promise what you can already deliver and motivate your teams to get you into a position where you can get ahead of the curve in order to do so.
There are 2 types of software products: products that are sold as is, and projects that are commissioned by clients with clear terms of execution & release…If we talk about deadlines – they are absolutely necessary only in case 2. Fortunately for Balsamiq – the product is in 1st category. Lucky you 🙂
Good luck and keep the same simple+intuitive ui/ux; then, for sure you can keep no-deadlines-philosophy 🙂
Pingback: No one wants to buy your iterations | lucisferre.net
This is the way I intend to run my current company.
In my last company, there were a couple of dynamics that drove us towards setting deadlines …
1) The phenomenon that work tends to expand to fill available time. Without a deadline for the next version, you might just work on it forever. This was pre-agile, but now with agile being the norm, this issue is largely addressed with sprints, etc. Also, I’m planning on working on each feature in separate branches, then collecting completed features together into a release, so that will help also.
2) The marketing team wanted lead time with the press. So if you want an announcement in the October issue, and the press submission date is a month earlier, marketing wants to guess when engineering will be done so they can get press announcements coincident with product availability. Now all the magazines have online equivalents that don’t have these submission dynamics, and as for printed magazines, I’m content to simply get the product done, then tell the press about it, then wait for them to print it. So what if it delays you by a month. That’s better than having to eat crow if you jump the gun, pre-announce something, get it printed, and then not be able to meet the date you set. Much less stressful I think. More conducive to quality work.
Traditional deadlines happen for a number of different reasons. Some I agree with, others I take issue with.
– Integrator’s schedule. In my world, we work with a lot of other companies that are solving other problems for the same group of buyers. We’re not interested in doing what they do and they don’t want to do what we do, but there’s more value to the buyer if our solutions work well together. If we miss an integration deadline we could be looking a a year or more before that chance comes again.
– Trade shows. Personally, I hate them, but I understand why they exist and their importance. It is, understandably, more effective to have a demoable product to unveil. Miss this deadline by a day and we’re looking at possible lost revenue from new buyers are the show.
– Demand from a customer. Best example I have right now is that of a new Enterprise customer that is switching to our service before the end of the year. Their contract with our competitor is up, they like us better, but we’re missing some items they have come to rely on over the years. They’re in our backlog, just have never been more important than other items. If we miss this deadline we’re looking at a bad first impression with a very large account. End of the world? No. But certainly not the best way to start off he long term relationship.
Arbitrary deadlines are unacceptable, in my opinion. They mean nothing and people aren’t willing to work as hard for them. Sure, they may turn in a 10-day project in 5 days, but there are consequences. Normally quality suffers and moral is hurt. Do this too frequently and you’re left with an inferior product and staff that interviewing instead of producing.
You’re on the right path. Your devout customer following is evidence of that.
This post was also discussed on Hacker News the other day: http://news.ycombinator.com/item?id=2968746 – good stuff!
Thanks all for the great feedback (also on Hacker News here: http://news.ycombinator.com/item?id=2968746).
I realize that I didn’t mention a couple of things that would make this post more clear:
– we release “all the time”. As soon as we have enough stuff in the codebase for a mini release, we push it out. This helps us keep our pace, it’s a constant internal pressure to keep going
– I’m a fan of self-imposed deadlines, nothing wrong with that
– someone asked how we know if we’re going fast enough: it’s mostly a gut feeling, but our output is easy to measure: how many releases we do, how many new tutorials or updates to the website we do, how long our support tickets stay unanswered…we look at that stuff every day, it’s easy to get a feeling of how fast we’re going at any given time. Plus I use DigMyData daily, which helps: http://blogs.balsamiq.com/peldi/2011/09/06/digmydata/
Thanks again for the feedback, I love these discussions!
I think that it’s very important to stay humming between 3rd, 4th and 5th gears — you can’t sustain a high-intensity pace forever. Deadlines, however, are a little different. Mockups is a great product, and we love using it in our portfolio — but it’s not mission critical. If y’all are “late” with a release it’s not going to affect us. However, we have other systems that are mission critical — and we have deadlines that are very necessary. In the case of true deadlines we need to set expectations properly at the outset and account for things that crop-up during execution — but we often still have to live with real deadlines.
Just to possibly pre-empt comments from some corporate subscribers, I know the importance of deadlines – I look after a multi-billion dollar B2B application portfolio. The one thing this has taught me is that customer perception is most important. Never implement elements that hamper the client UX and never over complicate things. Peldi and his team have a greats product, yes it’s niche, bu I addresses it beautifully, which after all is what it’s all about in the end.
Product, especially great product should never be dictated to by deadlines. Being Italian you understand the importane of allowing a good cheese to age and a great red wine to breathe. So it is with great software, and you build great software.
The problem you have with pace versus deadline is a simple one. Back to the analogy of food and wine here – spot the theme, even from a brit! Once you taste the goods you hunger for more. Therefore customer demand will always exceed your capability with respect to this aspect. We see great software, you sort of set the expectation of regular releases, so we expect great strides each release. This is not exactly your problem, but you did create it.
Take care my friend..
You have put words (pace vs. deadline) to a concept that I have been thinking about for a long time. The comments from people who appreciate deadlines I think are also aligned with your vision. What people want is structure and guidance. I think eventually you will find that you need to define “pace” better — and this will not require a new policy, but merely clarify your “first principle” so that newcomers that have not had the benefit of lots of 1-1 conversation with you can get it.
One of the ways we dealt with this in my software company was that we had quarterly releases, and goals for what features would go in each. But if they weren’t ready for prime time, they didn’t go in; they’d go in the next release. Sure there was a “deadline” for the code that was going to ship, and sometimes there was pressure to get a certain feature into a certain release because of customer demand. But in general, our quality was much better when we decided to focus on finishing features rather than shipping releases.
Another key thing about the company: it was a successful startup in
spite of competing with free products from three huge companies!
Keep up the great work — I think Mockups is one of the best pieces of software I’ve ever encountered.
Yes, times are good for you. Customers love you, money doesn’t seem to be much of an object, and you have no ‘suits’ to answer to; that’s most entrepreneur’s dream. I congratulate you and commend you on picking the right product at the right time with the right team, and being seemingly frugal about spending what money you already have.
Pace (or Velocity as referred to in Agile/Scrum) is very important. Your momentum on delivering work is very important, and making the car analogy is one I will surely use in the future! Changing gears should be anticipated, no matter how good of a team you are.
But as far as deadlines are concerned, I think deadlines are important to business.
I have seen that, for a given feature, if you give someone 10 days to something, they will take 10 days. If you give them 5 days, they will probably get it done in 5 days. Now, that is all relative, since different features/changes require varying amount of work, so I wouldn’t say cut all time in half. It all depends on the type of work, and the risk the change brings to the existing software or other parts of the software. What I’m trying to ask is, how do you know someone isn’t taking too long on a feature?
Hmm, sounds vague and frustrating. I like to set goals for myself even if they are self imposed. It gives me something to shoot for, to measure, and ultimately to improve.
Thanks Beck! We know when we’re in 4th gear when we’re able to do releases quickly, make updates to our website, publish new tutorials, our help desk queue is low…it’s fuzzy, but pretty easy to gauge. 🙂
As for structure, we talk about what we should do next on a daily basis. It’s not long-term structure, but we all know what’s important to do next. 🙂
There is life everywhere — a company no different — and as with all living, there is shrinking and expanding, along with uncertainty. If I think about work the way I think about life, it makes a lot of sense to consider pace instead of destination.
But what I like about deadlines is that they provide structure and structure is an essential building block in my creative process. How does pace provide structure for Balsamiq? How do you know when you’re in 4th gear?
Thanks Savvas and Bahadir.
@Bahadir, it’s true that it’s easy for us to work this way right now that things are going great, and it might not be as easy in the future. I am very much aware of that, and that’s why I think the team is the most important asset of any company. If you have a GREAT team doing what they love, everything else is easier.
Re: big player deciding to give a Mockups equivalent for free: why would they do that? We’ve demonstrated there’s money to be made here. And if they did, they wouldn’t last. A product that doesn’t bring in revenue doesn’t justify the resources allocated with it most of the time.
Re: someone else coming up with a competing product right now: we compete on usability and customer service. If someone out there comes up with a product/website that’s easier to use and provides better customer service than we do, they deserve to win. As for this new startup being backed by $50+ million VC money, I doubt that would happen (I’ve spoken to many VCs), VCs are looking for 10x returns in 5 years and our market is not that big. Also, VC-backed startups have a clock ticking on them, 9 out of 10 don’t last.
“The question is are you ready for bad times ? How strong are you as a company?” – those are great questions, and are always on my mind. Right now, I think we’re in really good shape.
Thanks for the feedback!
I think all it depends on the competition and the product-market fit. If your customers are happy with the product, and you provide the features that they really want; it is great. It is very hard to compete with you ( price, features, customer service, etc..)
How about the people who decides not to use “Balsamiq”.
Are they saying no because of some specific features ? or price ? What percentage of the market did you able to acquire ?
What happens when a big player decides to give their specific product that is targeted to your market for free ? or another Peldi developing a super cool product in a garage now, and will back up with $ 50+ Million VC money. May be at that time you need a sports car with 6th and 7th gear ( Need for speed ) to catch up!
I don’t mean you should grow the company to thousands of people. There are good times and there will be worse times as well. The question is are you read for bad times ? How strong are you as a company ?
When you are an automobile, it is nice to go with 4th and 5th gear. But if you are being a truck or a bus; you are not going that fast!
Deadlines are most of the time there for a sense of urgency and commitments to all the other parties in the equation. It is sometimes necessary but it is misused most of the time.
Think bigger companies can implement it even in a lower “version”. Its all about right management and organization.
You keep inspiring us Mr Balsamiq. Its always a pleasure to read your posts.
Gracias for sharing it.
Cheers from a neighbor. 🙂
Your email is never published nor shared.