Tag Archives: product strategy

Ready to build your product? Do this first.

Posted on by
Reply

stairway
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 ridejoy.com  (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

Posted on by
Reply

homer1

Inspired by: http://www.stanford.edu/class/e140/e140a/handouts/ProductMgmt.txt

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

Posted on by
Reply

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:

Rapport

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.

Portfolio

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)?

References

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.

Fake it till you make it

Posted on by
Reply

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:

Zappos

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)

TheLadders

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)

Aardvark

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)

Zynga

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).

 

Seamless

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)

Groupon

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)

Conclusion

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

Posted on by
Reply

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.

The first version of your product is going to suck… launch anyway

Posted on by
2

For most people the idea of launching a half-baked product is horrifying. You’ve been talking up your idea for months, been working crazy hours and even taken money from friends and family. This is the first time people will be seeing what you’ve been dreaming about and you want everything to be perfect. You feel like your entire reputation is at stake.

Unfortunately, you didn’t work with StartupGiraffe and things aren’t there quite yet. The site doesn’t work in IE (which your mom uses), crashes your browser if you click too many things too quickly (which your annoying co-worker has a tendency of doing) and is missing that killer “make my pictures look really old and cool” feature. So what do you? Launch anyway (to a handful of selected people)…

The first version of your product isn’t meant to have mass appeal. It’s purpose is to find out if you are heading in the right direction and see if you are really solving a customer need. The feedback you will receive will far outweigh the effort spent trying to “make everything perfect.”

The earliest stages of a startup focus heavily on product development. Launching early opens up a whole new world of awesome things to do for founders (especially non-technical ones). You can start acquiring customers, doing biz dev deals, speaking with investors, and planning v2 of your site (which will be much more awesome). In short, start demonstrating demand and traction.

Anyone disagree?

Why it’s Important to Share your Startup Idea

Posted on by
1

We speak with a ton of idea stage entrepreneurs through StartupGiraffe. Many times, people think we’re going to “Zuckerberg their Winklevoss” and steal whatever brilliant ideas they have. Because of this, they speak in generalizations and vagaries (it’s like LinkedIn meets Yelp for Healthcare with Farmville-style gamification). Unfortunately if you don’t tell us the details and motivations behind your project we can’t give any feedback or really figure out if working together is possible. We feel that you should not only tell us your ideas but share them with others too. Here’s why:

Talking is the Easiest Way to Get Feedback

The whole Lean Startup movement is about validated learning. You want to accomplish as much learning, as quick as possible with the least amount of effort. The easiest way to do this is by talking to trusted people.

Validation of the Problem Space

You need to find out if this is really a problem that other people have. While you may think it’s obvious that everyone would want to rate and review their pet food, that might not be the case. Research and fall in love with the problem not your solution. Find people who feel the pain most acutely, they will be the most enthusiastic about describing their troubles and why current solutions don’t suit them.

Developing Relationships with Early Cusotmers

Mark Suster talks about investing in Lines not Dots. He doesn’t want to invest in a single meeting with you, he wants to understand how well you work over time. There is a strong parallel here between getting early customers for your startup. The more you check-in, listen to feedback and demonstrate progress the more likely early customers will advocate and stick with you.

Here’s the #truth. No one is going to steal your idea.

Everyone has their own “Great Idea”

While your idea might seem brilliant to you, until you validate it/show traction/make money, it’s just another idea. Everyone has their own set of problems and set of experiences. In Eric Reis’ new book The Lean Startup, he suggests trying to take your (third) best idea and trying to find someone to steal it. Write blog posts , email product managers at Google and Facebook, go to meetings, tell everyone! Everyone’s busy with their own priorities and ideas, no one has time for yours.

Domain Expertise and Execution Matter

If someone can steal your idea based on a 30 minute conversation your idea is not defensible. Most likely you bring some secret sauce to the table (knowing the vertical really well, knowing people in the industry that you can sell to, etc…). You’ve been thinking about this problem/solution for weeks and months, it keeps you up at night, you get all hot and bothered just thinking of the potential. Anyone who steals your idea will always be one step behind, waiting for you to lead the way while they copy features. Your experience, execution and vision matter as much as your idea.

You will have Competitors

If your idea is based on the convergence of multiple trends (i.e. daily deals, group messaging, check-ins, photo sharing, etc…) there are likely multiple people with the same exact idea at roughly the same time. Regardless if you start to show success you will have competitors. That’s not necessarily a bad thing as it validates the space, creates competition for funding and creates buzz/pr/publicity.

Anything I missed? Any reasons why you still don’t want to share your ideas?

The Top 6 Mistakes Idea Stage Entrepreneurs Make

Posted on by
11

Since the launch of Startup Giraffe I’ve had the opportunity to speak to 50+ idea stage entrepreneurs.  I’ve been amazed at the diversity of good ideas that folks from outside of the startup scene have.  Through conversations with them I’ve realized that many could improve the way they think about launching products.  Here are some of the most common mistakes we see:

Feature Set is Too Broad for a First Iteration

Many entrepreneurs we’ve met want to build products for everyone.  Successful products start by having a tightly defined, niche audience and growing out from there. Products built for everyone serve no one.  If you can’t describe what your product does in one sentence, it’s probably too broad for a first iteration.  It’s great to have a big vision but the v1 feature set should only be a thin slice.

Not Defining Goals & Outcomes

After the product is built how will you measure success?

Do you want to see traction? Make sure you build virality into the product (don’t just tack on social invites at the end).  Make sure you can easily track how/when/why users are inviting their friends.

Do you want to raise a VC round? Talk to VC’s understand the metrics that they will use to calculate whether you are worth their investment.

Do you want to see if customers will pay for the product? Build in pricing up front, start measuring what percentage of your users convert to paid plans.

Building Functionality That Exists Elsewhere

Unless there’s a really compelling reason, most products don’t need to build their own chat, reviews, commenting, messaging, friending or following services.  You should focus on functionality that only your product offers and leverage third party API’s.  Don’t reinvent the wheel.

Thinking of UI Rather Than Tasks & User Stories

Many folks we speak to have done their own wireframes or have a strong idea of what the product should look like visually.  While this is extremely helpful in communicating the idea of the product, a better approach is to focus on personas and tasks.  Who are the archetypical users of your products?  What tasks do they want to be able to accomplish on the site?

I ask folks we work with to rank each feature by priority and how frequently the user will use it.  We then go in and estimate a level of difficulty for each task.  Based on this we can have a great conversation around scope.  Only once we understand the core feature set can we can start defining a minimal UI that addresses all tasks/user stories.

Not Speaking with Enough Potential Customers

Our team has gotten really good at trying to validate market fit before we write any lines of code.  We recommend that you speak to as many potential customers as possible.  Talk to real people about the problem you are trying to address not the solution.  Really try to understand their behaviors and motivations.  Whitney Hess has a great post about conducting user interviews.

Too Much Time Refining Details Rather then Executing

Many of the people we speak to have been thinking about their products for months. They’ve brainstormed every feature they can possible feature they can think of.  They’ve understood their goals and have whittled down their feature set to a true MVP, but yet they are still hesitant.  It isn’t perfect.  Unfortunately, it never will be.  The first iteration should be a tool to test your underlying assumptions and get you to the next level.  It’s a broad stroke that you will only be able to refine through metrics and observations/conversations with actual users.

Of course, there are many ways to get your product off the ground.   These are just our suggestions based on recent experience.  Agree or disagree?  Let me know…

Latest Venture: Startup Giraffe

Posted on by
28

Over the past few months my two buddies and I have worked on a bunch of different projects.  From StoryStack to  Tractorbe.am to AudioJux (plus a few others), we’ve realized a few things:

  1. We get all fired up about new ideas
  2. We’re really good at building the first iteration or two of a product
  3. We love working on a wide variety of platforms and across multiple verticals.

Today, I’m proud to announce our latest venture, Startup Giraffe: a product development shop focused exclusively on translating ideas into minimum viable products.  In other words, we’ll build the first version of your startup for cash and a small slice of equity.

We’ve started talking to a bunch of non-technical founders, business school students, corporate dreamers, and companies who don’t have the right type of in-house talent. We’ve realized that options for people to get a new product off the ground are extremely limited.  Existing development companies are charging huge sums for builds that are far more complex and time-consuming than necessary.

Our goal is to simplify and expedite the development process for entrepreneurs.  Here’s how we do it:

  1. We work with entrepreneurs to define their minimum viable product, or the simplest product they need to test their market assumptions.
  2. We collaborate with entrepreneurs on wireframes and graphic design
  3. We build the web or mobile application rapidly (typically 2-3 weeks)

Once we have delivered the first iteration of the product, our involvement becomes more strategic.  We offer technical, marketing and product feedback as needed.  With a first iteration in hand, entrepreneurs can then begin: validating assumptions, gathering customer feedback, raising funds and finding a technical co-founder.

I’m excited about this for so many reasons and really believe this fits our teams strengths and interests perfectly.

Got a project idea?  Get in touch at ak(at)amitklein(dot)com.

Deciding Between Startup Ideas

Posted on by
8

No one said working at a startup was easy. Although we started StoryStack with the intensity of a thousand suns we’ve hit a few bumps along the way. Through three iterations of the product and countless meetings with friends and advisors we’ve realized the product in it’s current form is unlikely to be successful.  We’ve found ourselves stuck somewhere between Informed Pessimism and Crisis of Meaning.  Now what?  How do we turn our passion and drive into productive energy?

We have a smart, resilient team and are throwing around new ideas all the time. Should we succumb to the sweet Siren song of new ideas? Do we stick by our guns and pivot and push forward?  Here are the factors we used to dictate our direction:

Addressing Pain Points –  Is this a product that customers are begging for?  There are a bunch of ways to test this before you write your first line of code:

  • B2B – Find potential customers and cold email them a brief description of your product.  If you find it easy to get decision makers on the phone or in meetings you’re in good shape.  If after your pitch you can get them to commit to purchasing your product when it’s ready, you’re money.  If they love it until you ask them to pay… tread carefully.
  • B2C – Setup a landing page (like LaunchRock) briefly describing your product.  If you have a little cash buy some Facebook or Google ads leading to your landing page and see the percentage of people who sign up (see Zygna’s Ghetto Testing).  If you’re broke: email, tweet and FB message your way to a sufficient sample size.
  • Another good indicator are homebrewed/hacked together solutions for the problem your product tries to address.  Are people stretching the limits of existing products or using multiple products in weird ways to get the same result?  People are lazy, if you make it way easier to do something they are already doing, you’re probably on track.

Strengths of your team –  If you taught yourself to be a your own technical co-founder and don’t have experience building scalable web products, tackling a mass consumer B2C web product might not be the best idea.  If you’re a good sales gal and know how to manage customer acquisition through multiple channels then the company you choose to build should leverage those skills.

The right market –  I loved these two posts from Elad Gil:

As you iterate in a market, you will often find that the initial idea you chose is less important then the broader market you are in.  A great market will always have opportunities in it.  Even if the first idea is terrible you will get to know the market and its needs and build something great on your next try.  In contrast a great idea in a terrible market will often fail. ~ You don’t need a good idea to start a great company

But how do you know if you are in the right market?   Paraphrasing from How Can You Tell If Your Market Is A Good One?

  • What’s changed about the market? Are there cost changes, new distribution channels or technologies?
  • Is the industry and customer base growing rapidly?
  • Is there a lot of interest in the market?

Passion - Even if you have the product that customers would line up for, fits excellently within the strength of your team and is in a killer up and coming market the number passion is still the most important factor.  Startups are hard.  Are you going to be thinking about your product 24×7?  Are you gonna love coming to work even when it sucks and it seems like you aren’t making progress?  Do you HAVE to work on this?

..the best startup you can create is one where you will be constantly engaged in thinking about improving the product, maximizing the user experience, and planning for the future -where you have real passion for making it work. ~ The Passion Gap: Why Foursquare, Groupon, Facebook, And Apple Are Winning

So what are we doing?  The short answer is that we’ve decided to delay the decision.  We’ve temporarily put StoryStack on the back burner and  while we work on a (soon to be announced) social, music product.  We’ll do a small launch next week, quickly reach the area between informed pessimism and crisis of meeting and go through the whole thought process again…