The most important thing in software development is motivation. Motivation is local — if you aren't motivated by what you are working on right now, then chances are it won't be as good as it should be. In fact, it's probably going to suck.
Long, drawn out release cycles are motivation killers. They insert too much time between celebrations. On the other hand, quick wins that you can celebrate are great motivators. If you let lengthy release cycles quash quick wins, you kill the motivation. And that can kill your product.
So, if you're in the middle of a months-long release cycle, dedicate a day a week (or every two weeks) for some small victories. Ask yourself "What can we do and release in 4 hours?" And then do it. It could be...
A new simple feature
A small enhancement to an existing feature
Rewriting some help text to reduce the support burden
Removing some form fields that you really don't need
When you find those 4-hour quick wins, you'll find celebration. That builds morale, increases motivation, and reaffirms that the team is headed in the right direction.
Source: svn
Tuesday, 20 December 2011
There's Nothing Functional about a Functional Spec
Don't write a functional specifications document
These blueprint docs usually wind up having almost nothing to do with the finished product. Here's why:
Functional specs are fantasies
They don't reflect reality. An app is not real until builders are building it, designers are designing it, and people are using it. Functional specs are just words on paper.
Functional specs are about appeasement
They're about making everyone feel involved and happy which, while warm and fuzzy, isn't all that helpful. They're never about making tough choices and exposing costs, things that need to happen to build a great app.
Functional specs only lead to an illusion of agreement
A bunch of people agreeing on paragraphs of text isn't a true agreement. Everyone may be reading the same thing but they're thinking something different. This inevitably comes out later on: "Wait, that's not what I had in mind." "Huh? That's not how we described it." "Yes it was and we all agreed on it — you even signed off on it." You know the drill.
Functional specs force you to make the most important decisions when you have the least information
You know the least about something when you begin to build it. The more you build it, the more you use it, the more you know it. That's when you should be making decisions — when you have more information, not less.
Functional specs lead to feature overload
There's no pushback during spec phase. There's no cost to writing something down and adding another bullet point. You can please someone who's a pain by adding their pet feature. And then you wind up designing to those bullet points, not to humans. And that's how you wind up with an overloaded site that's got 30 tabs across the top of the screen.
Functional specs don't let you evolve, change,and reassess
A feature is signed off and agreed on. Even if you realize during development that it's a bad idea, you're stuck with it. Specs don't deal with the reality that once you start building something, everything changes.
So what should you do in place of a spec? Go with a briefer alternative that moves you toward something real. Write a one page story about what the app needs to do. Use plain language and make it quick. If it takes more than a page to explain it, then it's too complex. This process shouldn't take more than one day.
Then begin building the interface — the interface will be the alternative to the functional spec. Draw some quick and simple paper sketches. Then start coding it into html. Unlike paragraphs of text that are open to alternate interpretations, interface designs are common ground that everyone can agree on.
Confusion disappears when everyone starts using the same screens. Build an interface everyone can start looking at, using, clicking through, and "feeling" before you start worrying about back-end code. Get yourself in front of the customer experience as much as possible.
Forget about locked-in specs. They force you to make big, key decisions too early in the process. Bypass the spec phase and you'll keep change cheap and stay flexible.
Source: svn
These blueprint docs usually wind up having almost nothing to do with the finished product. Here's why:
Functional specs are fantasies
They don't reflect reality. An app is not real until builders are building it, designers are designing it, and people are using it. Functional specs are just words on paper.
Functional specs are about appeasement
They're about making everyone feel involved and happy which, while warm and fuzzy, isn't all that helpful. They're never about making tough choices and exposing costs, things that need to happen to build a great app.
Functional specs only lead to an illusion of agreement
A bunch of people agreeing on paragraphs of text isn't a true agreement. Everyone may be reading the same thing but they're thinking something different. This inevitably comes out later on: "Wait, that's not what I had in mind." "Huh? That's not how we described it." "Yes it was and we all agreed on it — you even signed off on it." You know the drill.
Functional specs force you to make the most important decisions when you have the least information
You know the least about something when you begin to build it. The more you build it, the more you use it, the more you know it. That's when you should be making decisions — when you have more information, not less.
Functional specs lead to feature overload
There's no pushback during spec phase. There's no cost to writing something down and adding another bullet point. You can please someone who's a pain by adding their pet feature. And then you wind up designing to those bullet points, not to humans. And that's how you wind up with an overloaded site that's got 30 tabs across the top of the screen.
Functional specs don't let you evolve, change,and reassess
A feature is signed off and agreed on. Even if you realize during development that it's a bad idea, you're stuck with it. Specs don't deal with the reality that once you start building something, everything changes.
So what should you do in place of a spec? Go with a briefer alternative that moves you toward something real. Write a one page story about what the app needs to do. Use plain language and make it quick. If it takes more than a page to explain it, then it's too complex. This process shouldn't take more than one day.
Then begin building the interface — the interface will be the alternative to the functional spec. Draw some quick and simple paper sketches. Then start coding it into html. Unlike paragraphs of text that are open to alternate interpretations, interface designs are common ground that everyone can agree on.
Confusion disappears when everyone starts using the same screens. Build an interface everyone can start looking at, using, clicking through, and "feeling" before you start worrying about back-end code. Get yourself in front of the customer experience as much as possible.
Forget about locked-in specs. They force you to make big, key decisions too early in the process. Bypass the spec phase and you'll keep change cheap and stay flexible.
Source: svn
Monday, 19 December 2011
Hire Less and Hire Later
There's no need to get big early — or later. Even if you have access to 100 of the very best people, it's still a bad idea to try and hire them all at once. There's no way that you can immediately assimilate that many people into a coherent culture. You'll have training headaches, personality clashes, communication lapses, people going in different directions, and more.
So don't hire. Really. Don't hire people. Look for another way. Is the work that's burdening you really necessary? What if you just don't do it? Can you solve the problem with a slice of software or a change of practice instead?
Whenever Jack Welch, former CEO of GE, used to fire someone, he didn't immediately hire a replacement. He wanted to see how long he could get along without that person and that position. We're certainly not advocating firing people to test this theory, but we do think Jack is on to something: You don't need as many people as you think.
If there's no other way, then consider a hire. But you should know exactly who to get, how to introduce them to the work, and the exact pain you expect them to relieve.
Source: svn
So don't hire. Really. Don't hire people. Look for another way. Is the work that's burdening you really necessary? What if you just don't do it? Can you solve the problem with a slice of software or a change of practice instead?
Whenever Jack Welch, former CEO of GE, used to fire someone, he didn't immediately hire a replacement. He wanted to see how long he could get along without that person and that position. We're certainly not advocating firing people to test this theory, but we do think Jack is on to something: You don't need as many people as you think.
If there's no other way, then consider a hire. But you should know exactly who to get, how to introduce them to the work, and the exact pain you expect them to relieve.
Source: svn
Design the interface before you start programming
Too many apps start with a program-first mentality. That's a bad idea. Programming is the heaviest component of building an app, meaning it's the most expensive and hardest to change. Instead, start by designing first.
Design is relatively light. A paper sketch is cheap and easy to change. html designs are still relatively simple to modify (or throw out). That's not true of programming. Designing first keeps you flexible. Programming first fences you in and sets you up for additional costs.
Another reason to design first is that the interface is your product. What people see is what you're selling. If you just slap an interface on at the end, the gaps will show.
We start with the interface so we can see how the app looks and feels from the beginning. It's constantly being revised throughout the process. Does it make sense? Is it easy to use? Does it solve the problem at hand? These are questions you can only truly answer when you're dealing with real screens. Designing first keeps you flexible and gets you to those answers sooner in the process rather than later.
Source: svn
Design is relatively light. A paper sketch is cheap and easy to change. html designs are still relatively simple to modify (or throw out). That's not true of programming. Designing first keeps you flexible. Programming first fences you in and sets you up for additional costs.
Another reason to design first is that the interface is your product. What people see is what you're selling. If you just slap an interface on at the end, the gaps will show.
We start with the interface so we can see how the app looks and feels from the beginning. It's constantly being revised throughout the process. Does it make sense? Is it easy to use? Does it solve the problem at hand? These are questions you can only truly answer when you're dealing with real screens. Designing first keeps you flexible and gets you to those answers sooner in the process rather than later.
Source: svn
Wordsmith
If you are trying to decide between a few people to fill a position, always hire the better writer. It doesn't matter if that person is a designer, programmer, marketer, salesperson, or whatever, the writing skills will pay off. Effective, concise writing and editing leads to effective, concise code, design, emails, instant messages, and more.
That's because being a good writer is about more than words. Good writers know how to communicate. They make things easy to understand. They can put themselves in someone else's shoes. They know what to omit. They think clearly. And those are the qualities you need.
Other fact: clear writing leads to clear thinking. You don't know what you know until you try to express it. Good writing is partly a matter of character. Instead of doing what's easy for you, do what's easy for your reader.
Source: svn
That's because being a good writer is about more than words. Good writers know how to communicate. They make things easy to understand. They can put themselves in someone else's shoes. They know what to omit. They think clearly. And those are the qualities you need.
Other fact: clear writing leads to clear thinking. You don't know what you know until you try to express it. Good writing is partly a matter of character. Instead of doing what's easy for you, do what's easy for your reader.
Source: svn
Start With No
"We Don't Want a Thousand Features"
Steve Jobs gave a small private presentation about the iTunes Music Store to some independent record label people. My favorite line of the day was when people kept raising their hand saying, "Does it do [x]?", "Do you plan to add [y]?".
Finally Jobs said, "Wait wait — put your hands down. Listen: I know you have a thousand ideas for all the cool features iTunes could have. So do we. But we don't want a thousand features. That would be ugly. Innovation is not about saying yes to everything. It's about saying NO to all but the most crucial features.
Source.
Steve Jobs gave a small private presentation about the iTunes Music Store to some independent record label people. My favorite line of the day was when people kept raising their hand saying, "Does it do [x]?", "Do you plan to add [y]?".
Finally Jobs said, "Wait wait — put your hands down. Listen: I know you have a thousand ideas for all the cool features iTunes could have. So do we. But we don't want a thousand features. That would be ugly. Innovation is not about saying yes to everything. It's about saying NO to all but the most crucial features.
Source.
Ignore Details Early On
We're crazy about details.
The space between objects
The perfect type leading
The perfect color
The perfect words
Four lines of code instead of seven
90% vs 89%
760px vs 750px
$39/month vs. $49/month
Success and satisfaction are in the details.
However, success isn't the only thing you'll find in the details. You'll also find stagnation, disagreement, meetings, and delays. These things can kill morale and lower your chances of success.
How often have you found yourself stuck on a single design or code element for a whole day? How often have you realized that the progress you made today wasn't real progress? This happens when you focus on details too early in the process. There's plenty of time to be a perfectionist. Just do it later.
Don't worry about the size of your headline font in week one. You don't need to nail that perfect shade of green in week two. You don't need to move that "submit" button three pixels to the right in week three. Just get the stuff on the page for now. Then use it. Make sure it works. Later on you can adjust and perfect it.
Details reveal themselves as you use what you're building. You'll see what needs more attention. You'll feel what's missing. You'll know which potholes to pave over because you'll keep hitting them. That's when you need to pay attention, not sooner.
Source: svn
The space between objects
The perfect type leading
The perfect color
The perfect words
Four lines of code instead of seven
90% vs 89%
760px vs 750px
$39/month vs. $49/month
Success and satisfaction are in the details.
However, success isn't the only thing you'll find in the details. You'll also find stagnation, disagreement, meetings, and delays. These things can kill morale and lower your chances of success.
How often have you found yourself stuck on a single design or code element for a whole day? How often have you realized that the progress you made today wasn't real progress? This happens when you focus on details too early in the process. There's plenty of time to be a perfectionist. Just do it later.
Don't worry about the size of your headline font in week one. You don't need to nail that perfect shade of green in week two. You don't need to move that "submit" button three pixels to the right in week three. Just get the stuff on the page for now. Then use it. Make sure it works. Later on you can adjust and perfect it.
Details reveal themselves as you use what you're building. You'll see what needs more attention. You'll feel what's missing. You'll know which potholes to pave over because you'll keep hitting them. That's when you need to pay attention, not sooner.
Source: svn
Fund Yourself
The first priority of many startups is acquiring funding from investors. But remember, if you turn to outsiders for funding, you'll have to answer to them too. Expectations are raised. Investors want their money back — and quickly. The sad fact is cashing in often begins to trump building a quality product.
These days it doesn't take much to get rolling. Hardware is cheap and plenty of great infrastructure software is open source and free. And passion doesn't come with a price tag.
So do what you can with the cash on hand. Think hard and determine what's really essential and what you can do without. What can you do with three people instead of ten? What can you do with $20k instead of $100k? What can you do in three months instead of six? What can you do if you keep your day job and build your app on the side?
Constraints force creativity
Run on limited resources and you'll be forced to reckon with constraints earlier and more intensely. And that's a good thing. Constraints drive innovation.
Constraints also force you to get your idea out in the wild sooner rather than later — another good thing. A month or two out of the gates you should have a pretty good idea of whether you're onto something or not. If you are, you'll be self-sustainable shortly and won't need external cash. If your idea's a lemon, it's time to go back to the drawing board. At least you know now as opposed to months (or years) down the road. And at least you can back out easily. Exit plans get a lot trickier once investors are involved.
If you're creating software just to make a quick buck, it will show. Truth is a quick payout is pretty unlikely. So focus on building a quality tool that you and your customers can live with for a long time.
Source: svn
These days it doesn't take much to get rolling. Hardware is cheap and plenty of great infrastructure software is open source and free. And passion doesn't come with a price tag.
So do what you can with the cash on hand. Think hard and determine what's really essential and what you can do without. What can you do with three people instead of ten? What can you do with $20k instead of $100k? What can you do in three months instead of six? What can you do if you keep your day job and build your app on the side?
Constraints force creativity
Run on limited resources and you'll be forced to reckon with constraints earlier and more intensely. And that's a good thing. Constraints drive innovation.
Constraints also force you to get your idea out in the wild sooner rather than later — another good thing. A month or two out of the gates you should have a pretty good idea of whether you're onto something or not. If you are, you'll be self-sustainable shortly and won't need external cash. If your idea's a lemon, it's time to go back to the drawing board. At least you know now as opposed to months (or years) down the road. And at least you can back out easily. Exit plans get a lot trickier once investors are involved.
If you're creating software just to make a quick buck, it will show. Truth is a quick payout is pretty unlikely. So focus on building a quality tool that you and your customers can live with for a long time.
Source: svn
What's Your Problem?
A great way to build software is to start out by solving your own problems. You'll be the target audience and you'll know what's important and what's not. That gives you a great head start on delivering a breakout product.
The key here is understanding that you're not alone. If you're having this problem, it's likely hundreds of thousands of others are in the same boat. There's your market. Wasn't that easy?
When you solve your own problem, you create a tool that you're passionate about. And passion is key. Passion means you'll truly use it and care about it. And that's the best way to get others to feel passionate about it too.
The Open Source world embraced this mantra a long time ago — they call it "scratching your own itch."
Source: svn
The key here is understanding that you're not alone. If you're having this problem, it's likely hundreds of thousands of others are in the same boat. There's your market. Wasn't that easy?
When you solve your own problem, you create a tool that you're passionate about. And passion is key. Passion means you'll truly use it and care about it. And that's the best way to get others to feel passionate about it too.
The Open Source world embraced this mantra a long time ago — they call it "scratching your own itch."
Source: svn
Thursday, 24 November 2011
STANDING OUT FROM THE CROWD With Business Cards That Get Attention
What makes a successful business card?
A professional business card should be designed to attract and acquire new customers to your product or services. Not only is it an advertisement, a networking and lead-generating tool, it is a visual representation of you and your business. The bottom line is if it is not bringing you business and presenting a professional image of you and your company, it is not working.
For many people, the business card is the only marketing tool used, especially for those just starting in business. People frequently think a business card that can be designed and printed on their home computer will be a good enough tool to get them noticed and remembered. The truth is business cards are one of the most overlooked of all business tools. A well-designed, professional card makes you and your business look professional; a homemade business card typically gives the impression of an amateur taking a stab at being in business.
TIPS FOR BETTER BUSINESS CARDS:
· Use a compelling image that complements what you are trying to sell.
· Make it different enough to capture and retain attention.
· Use at least one hundred pound card stock and multiple, bright colours.
· Picture business cards with photos that stir emotion are some of the most effective, but are not appropriate for all business images.
· Use non-standard materials such as plastic or coloured stock, even something out of the ordinary is bound to be kept and remembered.
· Be different with shape, such as over-sizing the card or making it in the shape of your product.
· Changing direction with a vertical card can draw extra attention.
· Cards that fold in half or tri-fold can be like mini-brochures.
· Produce multiple interesting cards that encourage people to collect them.
· Utilize a noisemaker attachment, or even a distinctive scent, but do keep in mind that many people are allergic to perfumes.
· Include all standard contact information such as a company name, address, phone numbers, fax number, website and e-mail as well as your name and title.
· Include a logo, picture or graphic image that you will use consistently on all of your marketing materials.
· Include an advertising slogan that stimulates an emotional response, announces a distinctive brand identity and acts as a directory to your specific customer.
· Keep it simple with no more than a few different fonts and stay away from unusual fonts that are hard to read.
· Use a font size large enough for people of any age to read with ease.
· Never use cards with outdated information.
· Keep information to the point and as brief as possible.
· Utilize the back of your card for product information, testimonials, a special discount or free trial of your service, a calendar or something that they will want to keep and use.
THINGS TO THINK ABOUT
· Chances are that if you are not going through a few thousand business cards a year, then you probably are not close to utilizing every opportunity to market yourself and your business.
· If your card does not stand out when placed on a bulletin board with numerous others, it probably isn’t good enough to be remembered.
· When you hand your card to someone, if they do not make a favourable comment about your card, it is probably not good enough to be remembered.
· When handing out a business card, always ask for one back and utilize the opportunity to follow-up within a few days, adding this new contact to your mailing or E-mail list.
Win/Win Negotiation
What makes a successful negotiation?
You not only get what you wanted in the first place, but the person giving it to you is enthusiastic because the result benefits them too. Both of you feel a sense of accomplishment and you were each treated fairly in the process. The integrity of both parties is preserved and they are comfortable enough to want to deal with each other again. And there is a sense of security that both parties will keep their word.
TIPS FOR SUCCESS:
AVOID A MEETING ON THEIR TERRITORY
People tend to have the most intimidating power in their own environment.
- Meeting in a location where you feel the most comfortable will give you an advantage.
- If you cannot convince them to come to your location, try and offer to take them to a neutral location where you feel comfortable.
- If meeting at a restaurant or other public place is distracting or not private enough, then by all means find a location that suits you and the situation best.
PICK A MEETING AT THE TIME OF DAY WHEN YOU ARE AT YOUR BEST
- If it takes you hours to be really alert each day, then do your best to avoid meeting until later in the day; however, if you are sharp as a tack at 8:00 a.m. on Monday morning (typically a time when most people are most distracted), then schedule accordingly!
ALWAYS ARRIVE EARLY FOR YOUR MEETING AND NEVER, EVER BE LATE
- Being on time validates at least some of your professionalism and being late will disrupt their day and put you at an immediate disadvantage for everything you are trying to accomplish.
AT THE MEETING, POSITION YOURSELF FOR THE MOST POWER
- If you are alone with an opposing group, sit where you can easily make eye contact with all of them without stretching and turning.
- Learn their names and use them immediately. It helps you to prepare by getting the list ahead of time.
- If you have a large group opposing their small group, sit together for the influential power of the team.
- If they have a large group opposing your small group, then intermingle as much as possible to diffuse the influential power of their team.
PRICE IS NOT ALWAYS A KEY ISSUE
- Find out ahead of time what is the most important to them and figure out a way to fill their needs in your initial proposal.
THE FIRST PERSON THAT MENTIONS A NUMBER ALMOST ALWAYS LOSES
- Compromise is almost always expected in any negotiation.
- Never offer a range of numbers you will accept; it will instantly be assumed that you will accept the lowest number you mentioned or the middle one at best. Use this knowledge to your advantage if you are offered a range of numbers as your choice.
DRESS FOR PERSONAL EMPOWERMENT
- Prepare far in advance by pre-selecting the colours and outfit that not only fit the environment of your location and are appropriate for the situation, but that also make you feel enthusiastic and empowered.
- Never wear perfumes or colognes. Many, many people have allergies and this would disrupt focus.
- Clean breath with a smile and neat, clean appropriate clothing is essential. If you have tattoos, hide them. Keep jewellery, make-up, etc. to a conservative minimum.
- Be energized in your personality. Almost no one wants to do business with someone who is not enthusiastic. If this is not your general personality, then plan and prepare to make it happen.
Subscribe to:
Posts (Atom)