Co-Founder StartupGiraffe
Experience Designer
Software Engineer

Introducing StartupGiraffe for Non-Profits

July 8, 2014   -   0 comments   -  

At StartupGiraffe we love helping entrepreneurs build new products. Unfortunately there are many people out there doing great work who can’t afford top talent. We’re looking for an opportunity to give back to the community in a positive way. We’d like to to help a young non-profit establish their web strategy and presence. This includes up to 40 hours of our time for free to do any or all of the following:

  • Develop a digital strategy
  • Implement a website (preferably using wordpress or another similar CMS)
  • Create an adwords campaign (leveraging Google Grants)
  • Define and implement analytics
  • Additional miscellaneous tasks (setting up a newsletter, donations, etc…)

What we are looking for:

  • A 501c3 non-profit with a focus on kids, education or animals (areas we are passionate about)
  • A non-profit without a digital presence or one that sorely needs updating
  • A strong founding team who can carry forward with the tools/training we provide

We will be accepting applications for the next week (until July 14th) and perform the work at the end of July/beginning of August (we move quick!). We will accept one company from the current applications and consider expanding it for another round in the future.

To apply fill out the following form:

Introducing MiMi – The Magic Mirror

June 6, 2014   -   2 comments   -  


"Magic Mirror on the Wall, who is the Fairest one of all?"

“Magic Mirror on the Wall, who is the Fairest one of all?”

As hardware become cheaper and more powerful, everyday objects are starting to get smarter. Air conditioners, lights, scales, even your dog is now connected to the cloud. In a Star Trek future the objects in your life will know who you are and react to your intentions. At StartupGiraffe we’re really interested in the rise of smart devices. We wanted to dig deeper into building software for custom hardware by building a prototype. We went through a discovery/brainstorming process on what are all the objects in your house, and what could we make smarter with software (specifically embedded android). While we had a bunch of goodish ideas (a smart stove, chair, shoes), we ultimately settled on an Android Mirror:

Why Mirrors?

People spend on average around 50 minutes in front of the mirror a day.  While technology has permeated the rest of our lives, the bathroom mirror has remained largely unchanged.  But what if there was a device that could passively improve your health and make you feel better?  We came up with a list of ways a smart mirror could help.

The Use Cases

We wanted to focus our attention on bathroom mirrors since the use cases were more targeted.  The primary use cases revolve around health and beauty.  The following is a list of ideas we came up with for applications.

- Reminders of things to do every day (take your medicine, brush your teeth, floss)
- Information about medicines and dosages you should be taking
- Take photos of you every day and identify changes over time (your skin pallor is changing, you might want to check out that new mole)
- Make it more fun to get ready (did you know you should brush your teeth for 3 min everyday, here’s a short video to entertain you during that time)
- Gamify healthy habits for kids

- Try on virtual makeup and accessories
- Tutorials on new hairstyle
- Get ready with your friends (video chat)
- Tell you how great you are

The possibilities are endless.

The Hardware

The components include:
- A 24″ Asus monitor
- A one way mirror (aka interrogation room glass) –
- A wandboard with wifi, camera and mike
- A custom wooden frame
- Duct tape and inspiration

The Software

Ultimately we envision this as an open platform that other people can write apps for. We made some basic modifications to the stock Android OS (removing the soft buttons and rotating the angle to portrait mode). We also wrote an Android demo app.

The Demo

We were invited to participate in NYC Resistor‘s interactive show. We wanted to build something that was easy, looked good, and demonstrated internet connectivity and interactivity. We enlisted the help of Mark Forscher (who did an awesome job brainstorming with us and doing a quick design session – you should hire him).

The app is a photobooth that shows you a gif (via the giphy API) and asks you replicate it. The output is posted side-by-side to Tumblr.


Next Steps

We’re talking to a few people about other specific use cases (retail, hotels, advertising) to see if their is interest in further developing the product. If anyone would like to talk more about what what MiMi (or embedded Android) can do for you, get in touch.

The benefits and risks of consulting for equity

November 6, 2013   -   0 comments   -  

Cross posted from:

Disclaimer: This is not meant to be a comprehensive post just some things to consider. Always consult a lawyer and accountant before making decisions related to equity. Don’t take our advice, we’re developers not lawyers.


A friend of a friend comes up to you and wants your help. “We’ve got this new startup, we’re early but showing positive traction, we need your help to get us to the next level. We’re broke, but we can slice you off a chunk of equity in exchange for advisory/consulting services, interested?”

The company sounds intriguing and you’re willing to throw the dice. If you don’t have experience taking on equity there are a few things that you should consider:

Investing in a Good Startup Lawyer & Accountant
Taking equity is complicated. Find a good lawyer (we love ours!) and accountant and make sure you talk to them. Spending the additional time and money up front can pay dividends (pun intended) down the road.

You should check with a lawyer to see if you are able to take equity. Check your accredited investor status and note that there are specific securities regulation exemptions based on the state in which the company you are investing in must comply with. However, most states have exemptions for offerings to a small number (<25) of people and also for employees/consultants exchanging goods or services.

A common misconception is that there is no cost when taking equity. If you are being issued shares or a membership interest in a company you will need to declare the value and pay taxes on it. If the company is early stage then the value should be nominal. If the company has already raised funding (even from friends and family) or is generating revenue, then it may be greater than you expect. The company should be able to provide you with the valuation for any equity they issue to you. There are also additional costs related to legal, accounting, time & effort to consider as well. You don’t want to do all this work and then have a $40k tax bill from the equity down the road.

Vesting / 83b
If the equity you are receiving vests over time, it is important to consider filing an 83b. Filing an 83b within 30 days of receiving your equity can allow you to pay the taxes on the full amount issued to you up front rather than as it vests. This prevents the large tax bills that would arise if the company’s value increases sharply prior to being fully vested.

Equity vs Options
One possible way to avoid initial upfront taxes is by receiving warrants or options. By setting the strike price of the warrant equal to todays market value the warrant essentially has no value today. Only when the option is exercised (and the value of the underlying equity is greater than the strike price) do you earn and pay taxes on the difference. The downside is that you will have to pay a full tax rate on your profits when you exercise the option (as opposed to a much lower capital gains rate if you had taken equity).

How much equity should you receive?
This is always a tough question. You don’t want to take so much so that you are limiting the companies ability to raise money or attract future employees. If you are not a full-time hire, don’t expect to get more than a percentage point or two (and typically much less). Try to value your services as a cash rate and compare that to the value of equity you are negotiating. Make sure to discount the value you assign to the equity in this calculation to account for the many years it will likely take to become liquid and the very high risk that it never will.

How do you earn money on your equity?
The most common cases will be when a company has an IPO, is acquired or raises a round of financing where the founders take money off the table (sell their equity).

If the company is an LLC then typically any cash the founders take out needs to be distributed equally among its members (i.e. you would earn a percentage of the distributions). LLCs can be really flexible though and it is possible for the majority owners to change this. Be aware that if you are a member in an LLC you will have a tax obligation on the profits/losses they record (they need to issue you a K-1 at the end of the year that breaks down your share of their profit or loss) so at bare minimum you should ask that the company covers, via cash distributions, your tax obligations on profits recorded.

Most companies provide specific language in the company Shareholder or Operating Agreement limiting your ability to sell or transfer your interest. However most often you can ask for tag along rights (if the company sells shares you can opt-in to selling the same percentage of yours) and they will request drag along rights (you can be forced to sell when the founders do). As a minority holder it is unlikely you will receive any preference or other rights, and this is probably best for both you and the company. You should read and understand the Shareholder or Operating Agreement of the company to understand your rights.

Expect to be diluted alongside the founders in any fund raising round. If you own 1% and the company issues a 20% stake to a group of investors in a funding round, your stake will be diluted to 0.8. Most tech companies raise multiple rounds of financing with a 20-30% dilution each time, earlier rounds being typically more dilutive, and later rounds being less so. Also expect investors to get anti-dilution protection and liquidation preferences. The former could end up massively diluting your stake in the event of a “down” round, and the latter could prevent your stake from having much or any value in a distressed exit or “soft landing” scenario.

Is it worth it?
The harsh reality is that most startups fail and it is unlikely that your equity will be worth something. If you really believe in the team and opportunity, then go for it, but don’t expect to see a huge windfall. TechCrunch pins the average tech company acquisition at around $200m, but we’d guess the median is in the low tens of millions — for the 10% of companies that return at all. In most cases cash is king and unless you are building a portfolio, you may be better off offering your services at a discounted rate or with deferred (post funding) compensation.

Why You Should Timebox your Software Projects

July 17, 2013   -   0 comments   -  

Giraffe Clock

You’ve got a great idea for a new startup.  After doing some homework and getting customer validation you’ve decided it’s time to start building product.  You reach out to friends and development shops:

Here’s my great idea and a list of features/specs. How much is this going to cost to build?

You get some quotes and pick the option that’s within your budget.  Fast forward a few months later, your project still hasn’t launched, you’re significantly over budget and the product experience isn’t quite right.  What went wrong?

At StartupGiraffe we believe that timeboxing projects (a flat rate for a set period of time) is a better way to build software.  Here’s why:

You don’t really know what you need yet

Unless you have a ton of experience building software products, it’s unlikely that you’ve thought through the all the details related to the implementation of your product. Unfortunately it’s very difficult to do that up front (it takes time and exploration). As part of our process we usually give a few weeks up front for user interviews and product design. While the founder(s) we’re working with have a great high level understanding of the problem space and their solution, figuring out exactly how all users will use the system takes time. Defining a fixed scope engagement allows little room or incentive for for exploration during the process.

We can make it better

In a fixed scope model there is a fear of mid-project improvement. From the developers perspective new ideas are scary since it either creates more work or initiates the dreaded “out of scope” conversations (see below). In our projects there is typically a 30% variation in scope from where we start (what we think we will build) to where we end (what we actually build). This is a really good thing. In a fixed time project everyone can be strategic in coming up with high value changes based on iterative progress (wireframe, design, code) and feedback. Throw things away that are less important and instead improve the core of your experience. Everyone can be aligned to build the best product within the time period.

It forces you to prioritize

Some founders have a constant fear that they need “one more set of features” in order to start going out to customers. You can tweak details forever, but the best way to learn is by releasing a product to a small audience of real customers. Working backwards from a launch date forces you to focus on the most important / highest value things at all times. In the earliest stages your startup is still taking broad strokes. While the details are important, we often see folks spend way too much time on things which didn’t help them test assumptions or achieve their goals. You’ll learn more by launching quickly then continuing to develop low priority items.

“The biggest mistake I see is companies waiting too long to release the product. It’s easy to let the scope of what you’re building get out of hand. But equally importantly most startups build much more than they truly need to, but this is often only realized in hindsight. Whether your product is working or not, looking back it’s easy to see that you only really needed to build a small fraction of the stuff you built. Most features/options/buttons/settings/etc. simply aren’t crucial to success or failure, and for an early stage startup that means they were wastes of time — you could have done 10x more with that same amount of time and resources.” — Jonathan Wegener, Founder, Timehop and ExitStrategy

Everyone sucks at software estimates

Seriously. Until you get into the weeds it’s very difficult to know how long a particular development task will take. Not only is there undiscovered complexity and edge cases to deal with but no matter how well things are documented there is always room for misinterpretation. The only true way to ensure everyone is on the same page is by releasing code often and in thin slices. Only once you get your hand on something and play with it can you be sure it works the way you expect it to

In scope / out of scope conversations are the worst

Feature completion and what is classified as a “bug” is subjective. There is a lot of grey area. Trying to identify whether something is “complete” is not a perfect science. You don’t want to be having these conversations.

It’s cheaper

Yes it is. Someone on the agency side needs to calculate possible failures into a fixed price – in reality, you don’t get the lowest price, rather the safest for the company. The only person paying for this overhead is you. Dealing with a company that does not have those processes means that you are saving money and paying only for the actual work and experience. – Netguru

In the past we’ve also seen other teams “bid low” for a project, knowing they can make up the difference on their real cost with “out of scope” features.

You can plan better

Working backwards from a soft launch date allows for much better planning. From the startup’s perspective they can start planning everything that surrounds a launch (customer acquisition, support, fundraising, etc…). From our perspective we have much better resource planning and know when we’ll be available for new work.

While working on a timeboxed model requires there to be trust on both sides, we’ve found our projects are much more successful this way. Questions? Let us know.

Ready to build your product? Do this first.

March 26, 2013   -   0 comments   -  

We often meet with folks who are at the earliest stages of their entrepreneurial ventures and are unsure how to go from idea to product.  After an initial meeting we send them the following recommendations on how to give us (or any other team members) enough context to get started.

1. Provide Background Info

2. “Problem Discovery“ (i.e. conduct 20+ user interviews)

Our natural tendency is too think of solutions first (wouldn’t it be cool if this existed?).  Oftentimes there are many different ways to tackle the same problem.  Fall in love with the problem space and not your particular way of solving it.  It may make sense to take a step back and let your target audience define patterns and validate the problem before addressing solutions. We’d recommend finding people in your target audience and asking questions like:

  • How do you currently do [x]?  What tools do you use?  What do you love/hate about them?
  • When do you do this (at home, at work, on the go)?  How often do you do this?
  • In a perfect world how do you do [x]?
  • What are the factors that influence your decisions?  Rank them based on priority.
  • Where/how do you involve other people (experts and friends)?
  • What are the most time consuming tasks? Where do you make mistakes? What are your biggest frustrations? Where does it get expensive?

etc…  I really like this post on conducting user interviews.

3. “Solution Discovery” (i.e. Fake it?)

After you’ve done a bunch of user interviews patterns will start to emerge.  Are there ways to validate that your solution is one that people would want to use / pay for (see Concierge Testing)?  Can you manually provide this as a service (not to make money but learn the in’s and out’s) before productizing?

4. Define Personas

You’ve now got a clear validated solution and it’s time to scale up with product.  Who are your target users (we’d suggest targeting 2 or 3 different types of users initially)?  What are their main motivations?  What pisses them off?  We’ve put together a light template document for a site like  (see tab 2 of this doc).

5. Prioritize User Stories

For each of the users you described above, what are the main actions they want to accomplish using this product.  We believe it’s really important to bucket these into critical (you cannot get a customer without), nice to have (in a world of infinite time and money you would do) and things for the future (but not required for your v1).  See a sample on tab 1 of this gDoc.  Remember, you won’t “win” on features.  Building a simple product is hard.

Doing the steps can help you communicate and de-risk a lot of the steps of early stage product development.  Want more reading? Check out these additional links and this talk.  Want to talk about launching a new venture?  Get in touch.

Good Software Project / Bad Software Project

January 18, 2013   -   0 comments   -  


Inspired by:

Good software projects have clear business goals and objectives. Everyone on the team has an understanding of what metrics will be used to define success. i.e. Implementing these changes to the sign up flow will increase paid conversion rates. Bad software projects are driven by the loudest voice in the room and based on personal preferences. Success cannot be measured because it was never defined.

Good software projects are built initially for a specific target audience based on customer development and hypotheses. i.e. We interviewed 100 used car salesmen and found out their most time consuming task is following up with potential buyers after test drives. Let’s build a mobile web app to let them take notes and send follow-ups while they are still with customers. Good software projects start by doing one thing 10x better than anyone else. Bad software projects are built for everyone. These projects are incrementally better then their competitors and try to “out-feature” them. They are everything for everyone and fall short. They are built because they could, not because they should.

Good software projects have a plan to acquire users after launch. i.e. Through our landing page we’ve accumulated over 1000 emails. We also started a influencer campaign with the top bloggers and Klout scorers in this space. We’ve also set aside $2,500 to test Google Adwords and Facebook campaigns. Bad software projects rely on hope and a ”build it in and they will come” mentality.

Good software projects have a shared sense of ownership and are built with passion and love. Everyone is willing to step outside of their comfort zone to learn new things and attack new problems. Bad software projects have people finger pointing, and people who live within their title and place. “I can’t fix this, I’m just a junior developer. Ask Joanne, she wrote this.”

Good software projects have teams who pay attention to details without getting hung up on them. They are able to make decisions quickly and move on. Everyone working on the project has context. Bad software projects are built by teams without expertise. They spend weeks arguing over the shade of green on a button.

Good software projects release software as frequently as possible and get constant customer feedback. They have product owners who have a deep understanding of their users and are able to prioritize features. Everyone tests and logs feedback. Bad software projects stay in a black box for weeks and when finally released are underwhelming. Everything is equally important.

Good software projects ship, measure and learn. Bad software projects don’t.

Need Help Fast? When and how to hire a dev shop

July 23, 2012   -   0 comments   -  

Cross posted from the StartupGiraffe blog

Debates rage on whether companies who outsource all or parts of their development can be successful or not. In a perfect world you would have a brilliant in-house team that crushes features faster then you can think them up and has previous experience building similar systems. In reality this almost never happens. While long-term reliance on a development shop probably isn’t a great strategy there are a few situations where short-term engagements make sense.

When to hire a dev shop

You need help getting to that next major milestone

The appetite for great technical talent is at an all time high. Good technologists can get multiple offers for market rates + equity in a startup. Maybe you can’t afford the superstar you want or your company just doesn’t have the same cachet as competitors. Having an outside team help you with your next major release could allow you demonstrate the traction you need to get investment or attract that elusive hotshot developer.

You need outside expertise

Sometimes your in house team just doesn’t have the right sort of skills. Need a Facebook app or help optimizing your Mongo cluster? Finding a team that has done this before could save you time, money and heartache. Ideally you can have this outside team mentor and bring your insiders up to speed.

You have significant time contraints

Want to get in the App Store before the new iPhone hits stores? Have a competitor launching a new product? Have an external deadline by a partner? Hiring takes time. Augmenting your team with outside talent in short bursts can be effective.

How to hire a dev shop

So you’ve decided to take the plunge and hire a team. How do you know which team is the right one? What do you look for? What questions should you ask? Here are some things to look for:


The most important thing when choosing a partner is finding someone you feel comfortable with who understands your vision. Do they “get” what you are trying to do? Do they listen (really listen)? Do they ask the right questions? Do they speak your language? Do they have the right “context” for the business you are trying to build? Do you have a clear understanding of their process? Many times it’s hard to get this level of comfort with an offshore team. Even though local teams will probably be more expensive, the end results are usually better because of easier communication and shared context.


Is their work awesome? Do you see multiple examples of projects they’ve done that you are impressed by? Have they worked on projects similar to yours? If not, have they worked with clients similar to you (in terms of size/stage/industry)?


Always ask for references. The company will probably send you the three clients that love them the most, but dig a little deeper when speaking with them. Ask tougher questions. What were you surprised about when working with AwesomeDevShop? How did they do compared to your initial expectations? Where were they strongest? Where were they weakest? If you could do it over again what would you do differently? Was the timing or pricing different from what you initially agreed upon? Did you need to go back to them after the project was over for more work? How was that interaction? Would you work with them again? Not everything will be glowing but you should have a realistic expectation of what you are getting yourself into.


Finally always remember that software is never complete. While a dev shop can be a great stop gap solution, you’ll be responsible for owning the code once they leave. Make sure you have a clear exit strategy and an understanding of how you will handle ongoing maintenance and support.

Happy Birthday StartupGiraffe!!

May 16, 2012   -   0 comments   -  

Cross posted from the StartupGiraffe blog.

A year ago Startup Giraffe was born.  Looking back it’s amazing how far we’ve come.  Like most business, our first few months was about getting our head above water, earning enough to pay rent, tweaking our business model and learning the legal, accounting and general ins and outs of starting a new company.  We made a lot of mistakes but were lucky enough to experience some successes too.  Today, we have lots of good problems related to growing our business sustainably.  The more startups we launch, the stronger our ability to execute and support our companies becomes.

Some quick highlights of our accomplishments from our first year:

  • We’ve grown our team from two to four full time giraffes plus a partnership with an awesome design agency.
  • We’ve launched 11 companies and empowered 25 entrepreneurs to take the leap from idea to starting their own company.
  • We’ve proved that partnering with the giraffes to jumpstart your initial development can lead to traction, revenue, significant business development partnerships, outside financing, and full-time job creation (including recruiting in-house technical teams).
  • Our portfolio companies have been featured in the NYTimes, Mashable, Forbes, Huffington Post, Fashionista, Business Insider, WWD and other major publications.
  • By being smarter about how we build product we’re able to do more with less.  We’re now able to launch a thin slice of any idea in 6 weeks while maintaining lives and relationships outside of the office and working at a sustainable pace.
  • We’ve bought hundreds of dollars worth of giraffe gear including a giant stuffed giraffe, hats, dope t-shirts and cute mittens.

While we still have a lot of questions and there is a lot we don’t know, we’re thrilled about the path we are on.  Final thought… giraffes are awesome:

Fake it till you make it

March 8, 2012   -   0 comments   -  

Cross posted from the startupgiraffe blog

How do you validate your startup idea and start gaining early traction, without spending a ton of time and money building software? Delay complexity as long as possible by doing things manually. “Fake it till you make it.”

Below are some examples of how successful companies smoke / ghetto / wizard of oz tested their ideas:


In 2000 it wasn’t clear that purchasing shoes online was a great business.  Shoes have different fits and comfort levels and many thought they needed to be worn before they were sold.  The riskiest question for founder Nick Swinmurn’s fledgling company was:  ”Will people buy shoes online?”  One way to answer this would be to go out and raise millions of dollars in financing, build a huge warehouse, fill it up with shoes, build a comprehensive ecommerce system, hire a bunch of folks, cross your fingers and pray people placed orders.

Nick realized there has to be an easier way to de-risk his business.  Instead he went to Foot Locker and took pictures of their inventory.  He put photos of the shoes online.  Every time someone placed an order, he went to Foot Locker purchased the shoes and mailed them to the buyer.

Is this model scalable? Nope.  Did he make money on each order? Nuh uh.  Was he able to prove that people would by shoes online and get some early traction?  Yes.  (source: The Lean Startup)


In 2003, Marc Cenedella saw the difficulty executives were having finding new jobs online.  Wouldn’t it be great if there was one place that listed only high end (in this case $100k+) jobs?  Is that a service that job seekers would pay for?

Marc’s initial “prototype” involved going out once a week and browsing HotJobs, Monster and other job boards to manually collect $100k+ jobs.  On Monday mornings he would send a newsletter to job seekers containing only these 6-figure jobs.  He charged $25 to subscribe to the newsletter and his audience quickly grew through craigslist postings and word of mouth.

After we had been doing that for about nine weeks, I missed the 9 a.m. Monday deadline… At around 9:10 I started getting e-mails from people asking where the newsletters were. Those e-mails kept coming. That’s when I really knew I was onto something. That was the moment of validation.

Having passionate users who care when you mess up is an awesome sign of product-market fit.  Once a manual approach no longer scales you are in a great position to start automating these pieces with software.  (source: Sramana Mitra)


Google is really bad at answering questions like: Where should I grab a drink in SoHo after work?  Should I go to business school?  Which DSLR camera should I buy?  On the other hand, people are really good at answering these questions.  Aardvark was started as a social Q&A service.  You would send Aardvark a question over instant messager.  Aardvark would do some magic and get 3 people to answer your question and send it back over IM.

The most technically complex piece was the algorithm to find the right 3 people to answer your question.  The folks at Aardvark realized that although there was a large technical hurdle, the riskiest question to the success of their business was not can we build it, but will people use it. Rather then spending time initially to build out the algorithm they used a Wizard of Oz approach:

Aardvark employees would get the questions from beta test users and route them to users who were online and would have the answer to the question…  While it used humans “behind the curtain,” it gained the benefit of learning from all the questions, including how to route the questions and the entire process with users.

(source: Dean Eckles)


Taken from my previous post on: 8 Lessons Learned from Zynga about Virality

In the last 5 minutes of the video below Zynga’s founder Mark Pincus is asked what’s the best way to do market research. His answer – “Ghetto Test”. If someone wants to build, let’s say, a hospital simulator he creates an FB ad that says, “Ever wanted to run your own hospital?” which leads to a survey (or if it’s really ghetto a 404 page).

All Zynga has to do is track CTR and compare it to previous historical rates to get a pretty good idea of demand.

This works great if you are comparing multiple game concepts, product ideas, taglines, names, etc… though isn’t a good fit for testing out a new concept (without a comparison).



The folks at seamless allegedly spent their first few months without a web product.  They called up law firms in NYC and asked what they wanted for lunch.  They called the restaurant, placed an order, managed delivery and billed the firms at the end of the month. (source: anecdotal)


Andrew Mason and the team at Groupon launched the first version as a wordpress site.  Besides posting a deal, everything else was manual.

It was totally ghetto. We would sell t-shirts on the first version of Groupon. We’d say in the [write] up, ‘This t-shirt will come in the color red, size large. If you want a different color or size, email that to us.’ We didn’t have a form to add that stuff… It was enough to prove the concept and show that it was something that people really liked… It got to the point where we’d sell 500 sushi coupons in a day and we’d send 500 PDFs to people with Apple Mail at the same time.

(source: Weblogtoolscollection)


There are obviously situations where a lean approach doesn’t apply (i.e. google the search engine or an iPad).  For the large majority of startups today the biggest question is not can we build it, but should we.  Before you go ahead and spend a ton of time and money building complex technology, try to manually execute parts of your business for a small target audience.  Once things are working and you are unable to scale, then invest in technology to automate.

Any other good examples that we missed?



Steal This Product Idea #5 – Personalized Retail Shopping

January 27, 2012   -   0 comments   -  

Find the stuff that suits your tastes quickly

For all the advances in consumer technologies, walking into a retail store and making a purchase still feels like a “outdated” experience.  There’s a ton of relevant public information that I’d gladly provide to retailers in exchange for a more personalized shopping experience.  But despite the proliferation of social data, most retailers don’t know anything about me until I make a purchase.  

Here’s the idea:
  • A mobile app that links with your Foursquare/Facebook account.
  • You fill out a basic profile including your size and (possibly) the types of items you are interested in purchasing.
  • When you check into a store a salesperson gets a notification with your first name, photo, size, history of check-ins at that store, things you might be looking to buy, previous purchases and relevant notes that have been inputted by previous salespeople.  This may include previous items you’ve tried or comments about your style/preferences.
  • Future iterations might:
    • Notify you when an item you like is on sale/in-stock/available in your size.
    • Send you in-store offers on items you might be interested in purchasing.
    • Notify stores ahead of time that you are coming so they can have things ready to show you.
What’s in it for the shopper?
  • First and foremost a faster, more customized shopping experience.  Salespeople will know the size, style and preferred brands of shoppers.  Get in and out faster.
  • Targeted discounts on items they want to purchase
  • Perks (glass of champagne for those who share their info?  5% off?)
What’s in it for the retailer?
  • Push people through the sales funnel faster by showing them products in their size or those that suit their style.
  • Upsell shoppers on products they’d be likely to buy.
  • Build loyalty through a higher quality shopping experience and rewards/incentives.
Target Audience – I imagine this would be tough to implement in the larger department stores at first, but there are plenty of smaller retailers with fewer customers that would have the ability to really tailor the experience based on shopper.

In the end we don’t have the domain experience to be able to execute on this well.  If there’s any retail guru’s out there who want to collaborate, get in touch.

Update: Signature got a nice Techcrunch writeup and seems to be attacking the same problem.  I still think there is huge opportunity in this space for multiple players.

208 posts have been published
With a total of 472 comments