There it is. There is no more. For now. Except that we are looking for a someone special.

Front-end Engineer (UI/UX)

Shopximity, an early-stage startup, is looking for a front-end engineer. You’ll work with industry-leading Bocoup engineers and an experienced team of startup veterans at Shopximity to develop a system that will improve the user experience of 100 million people daily. As the first front-end engineer, you’ll both define and solve the many interesting problems we face as we develop the product from scratch.

In case you are not the right person but know someone who is, we offer a $10K referral bonus. Try us. Tell us about your worst competitor’s best engineers and we’ll hire them away and send you $10K.

Requirements and qualifications:

• Thorough experience with JavaScript, HTML, and CSS (we use JQuery).
• Thoughtful interaction design and sensitivity to user experience.
• Experience working with high-traffic websites (>500k monthly uniques).
• Entrepreneurial approach to your work. We don’t want to manage you, we want to enable you to make the product better and its users happier.

Things we’ll like about you:

• You are a problem solver and you like gnarly problems.
• You care deeply about user experience and empowering users.
• You’ve worked at, or are very interested in, consumer web startups.
• You’re always thinking about ways to make your favorite websites better.
• You’re interested in the mobile web, too, and have some ideas about designing for smaller screens.
• You’ve worked with a backend framework like Rails (which we use), Django, etc.
• You’re not afraid to voice your opinion and argue for it, but want to arrive at the right decision after thoughtful debate about what’s right for the product and its users.

Things you’ll like about us:

• You’ll work with, and learn from, people who have built many startups before, taken them public and won TechCrunch 50 awards. Think a startup bootcamp but faster paced.
• We have a mission. It is to make shopping better for everyone on Web and mobile.
• We use a cutting-edge stack in the cloud that will handle many billions of requests.
• We’re well-funded and backed by some of the best investors from the East and West coasts. Well-known people in our industry have joined as advisors to help us in our mission.
• We take care of our engineers. We have a bright office next to the Alewife T Station. Every workstation has two top-of-the-line monitors and an adjustable-height desk.
• Generous compensation, including ground-floor stock options. We want to hire the best and treat them like the best.
• We’re very early stage (5 people) and you can make a meaningful difference immediately because we run weekly sprints.

Please send your resume as well as links to your portfolio, GitHub or Dribbble. Include links to professional or community projects you’ve worked on. Additionally, please tell us a few sites whose UI/UX you admire, and tell us why.

[Tweet to tell your followers to come!]

You’ll hear from the following top marketers and entrepreneurs:

• Adam Berrey, Free Agent. Adam has spent that last 17 years working in technology marketing covering the full spectrum from strategic marketing through marketing communications at companies such as Allaire, Macromedia and Brightcove.
• Chris Hulls, the founder & CEO of Life360, is at the forefront of rethinking mobile marketing through the lens of value-added service integrations.
• Chris Savage, Founder & CEO, Wistia, a startup he co-founded a year after graduating from Brown University with a degree in filmmaking. Chris was named a Best Young Entrepreneur by BusinessWeek in 2009. Chris helped produce and bring to theaters an Emmy award winning film, “Buddy.”
• Christopher O’Donnell, director of product management at Hubspot, the inbound marketing company, where he arrived via the Performable acquisition. Christopher is a mentor to many and a well-known expert on performance-driven design. He likes making something amazing out of nothing.
• Dave Balter, Founder & CEO, BzzAgent (Dunn Humby). A co-founder and current executive council member of The Word of Mouth Marketing Association, Dave is an international speaker on the topic of word-of-mouth marketing. Dave built and sold two promotional agencies prior to forming BzzAgent.
• Sarah Hodges, Director of Community Marketing, Runkeeper. Sarah is a well-known digital marketer and blogger who practices a data-driven approach to marketing. She is an expert in viral marketing using emerging channels.
• Sim Simeonov, founder & CTO of Shopximity and a board member of MITX, the organizer of FutureM. He invests in and advises startups through FastIgnite and is a TechStars mentor. Sim has been a founder, CXO, investor and board member at more than a dozen startups. He likes big successes and small failures.
• Stephanie Shore, VP of Marketing, ZipCar. Stephanie is a marketer with deep intuition about both content and people. She is an expert at helping people express themselves within the context of a brand experience. Before ZipCar, Stephanie helped people make sense of the world around them through boston.com.

The hashtags for this event are #FutureM and #MSSS. Please, thank my co-host Christopher O’Donnell, our sponsor @shopximity, @wayfair (CSN) for hosting us in their great space and @FutureMBoston & @MITX for making it all possible.

The reason is simple. If a company is willing to pay $20+K to a recruiter for a great hire, why shouldn’t it be willing to split that bounty with someone else who gives them a great lead? It’s less about the actual dollars and more about the fairness of it. I’ve had people tell me they wouldn’t take the money. That’s cool. I can make a donation on their behalf or give it to a startup organization or a movement such as #RubyRiot.

The rules are simple:

1. No spamming. Any referral must come with clear reasons why you think the person would be great at a ground-floor startup. Please, respect our time.
2. Whoever refers a person first wins unless the quality of referral varies substantially, e.g., just mentioning someone you don’t know vs. mentioning a friend and offering an introduction. Within reason, the later but stronger referral would win.
3. The usual recruiting fee restrictions apply.
4. Yes, you can refer yourself.

Because of the strength of our founding team and our investors, we are going after some wonderfully tough problems. Here are the types of talent we are looking for:

• From a culture standpoint, we want curious, high-energy, hands-on, know how to ship, agile everything engineers who take pride in their work and in making customers happy. People who see technology as a tool, not an end. These are the kind of people who know that a problem must be fixed twice: the first time to make it go away and the second time to make sure this type of problem never reaches production again. The best of them know how to have fun after work.
• From a platform standpoint, we touch iOS, Android, Web and mobile Web (HTML5 + AJAX), Java + Python and/or Ruby. Hadoop and NoSQL work is guaranteed as is cloud deployment.
• From a development process standpoint, we aim to be extremely agile with short iterations and very small integration batch sizes (continuous integration for sure with the goal of continuous deployment). This makes for the most satisfying, high-velocity environment to write code in.
• From an experience standpoint, we are looking for both experienced senior/architect-level engineers who have “done it before” and rockstar junior engineers that can do it because they don’t know it couldn’t be done.
• We are good mentors–check us out. It really matters to us that the people on our team have fun while developing in their careers so that they can do whatever they want (get promoted, start a company) next time around.

Here are some tips:

• You don’t need to send a resume or get someone interested in working with Shopximity before referring them. Sometimes, the best thing to do is simply to identify someone truly great and let us take it from there. Shopximity is doing some pretty amazing things and so far everyone we’ve reached out to has been interested in being considered for our team.
• Don’t worry about specific job titles–those are fairy flexible based on the candidates’ career goals and experience. Just point us to great people.
• Mess with your competition: if your competitor has some great people on their team, tell us and we’ll recruit them away.

Let’s get going. Follow me @simeons and send me an email at sim at shopximity dot com if you have someone for us.

Much of the fundraising advice entrepreneurs get is extremely tactical, e.g., say the following thing on this slide or don’t say “platform”, etc. This may make a first meeting with investors go better but usually leads to disillusionment and a pass later on in the process. It’s a lose-lose proposition. Both sides spend precious time and go nowhere.

I prefer a more fundamental approach, one that attempts to help build a business with fundraising simply an artifact of that broader goal. A founding team must discover its core strength and the reason why they, as opposed to the other dozen smart teams going after similar ideas, are going to win. This requires intellectual honesty and emotional maturity. It’s hard work. It may point out significant holes in a team’s capabilities or issues with the company’s business model. Then the work gets harder. Companies that face these challenges come out stronger and much better prepared to raise money and grow.

Here are a few of my posts I tend to refer founders to over and over. I hope you find them helpful.

• Agile ideology
• How to raise money without lying to investors
• When to fire your co-founders
• Ten rules for better founding teams

A great starting point for practicing agile ideology in startups is The Startup Holy Trinity:

• Agile development for high-velocity product execution
• Cloud deployment for managing operating costs
• Customer development for achieving product/market fit

Pick a methodology and, unless you are already an expert in it, follow it blindly for two iterations. Put incentives that support your team’s blind faith. Make it fun. Make it competitive. Make it understood exactly when blind faith will go away.

Unless you have a very good reason or two why your product can’t be running on infrastructure-as-a-service (IaaS) or, even better, a platform-as-a-service (PaaS) provider, try the cloud. Take the top two reasons why you think you can’t deploy to the cloud and question the assumptions they are based on. Early stage startups don’t have Innovator’s Dilemma but their founders do. Don’t be like those to looked at Windows 3.0 in 1990 and thought they needed their Unix workstations or like the those who laughed at the Web’s clunkiness in 1994.

Customer development is the tricky one. The methodology is iterative and self-regulating but the iteration lengths can vary. It’s easy to know when to initiate blind faith but not so easy to know when to stop. It’s an issue a number of us are starting to think about and one we’ll cover at Customer Development: The Second Decade.

Where I will deviate from the traditional lean startup thinking is on the topic of bootstrapping. I simply do not see the type of fundamental, long-term transformational benefits coming from bootstrapping that I see from agile development, cloud deployment and customer development. Don’t get me wrong, I like bootstrapping, have used it and have recommended it to others in the right circumstances. But bootstrapping has an opportunity cost and there are common anti-patterns that lead startups to under-perform in bootstrap mode.

I am not a fan of ideologies. Inflexibility of thinking or the ability to take reality into account rarely leads to great outcomes. Just look at history. Methodologies, on the other hand, I like. The difference between the two is in the level of critical thinking. A good methodology isn’t just a set template. It is an evolving, data- and introspection-driven process that’s very much reality-based.

There two big problems with methodologies, or rather, with the way we adopt them that lead to failure. The first is lack of commitment. The second is premature optimization.

Many methodologies require a significant investment of time and effort, not just of an individual but of entire teams and organizations, before the benefits start showing up. The animal brain inside us doesn’t like delayed gratification. We invest half-heartedly into a methodology and then back out. It’s like quitting karate training after a year because we can’t split bricks with our bare hands. Early data can be too random due to poor selection of data sources and small sample sizes, as in the case of a startup’s first customers. We have to give the new thing a chance.

At times we start tinkering with a methodology too soon, before knowing enough or having enough experience to understand the trade-offs we are making. We call it “adapting the process to our special circumstances.” (Funny how every one has special circumstances.) This is premature optimization–which is “the root of all evil” according to the venerable Donald Knuth. In agile development, for example, Jeff Sutherland, one of the creators of Scrum, calls this practice of the methodology “Scrum But” as in, “we do Scrum but in our case we don’t do A and B and we’ve started doing C.” Jeff and other agile practitioners have overwhelming evidence that organizations with little agile development experience are much more likely to lose than gain when they customize a methodology before having developed the experience and judgment to understand the impact of the changes.

I see many examples of useful methodologies failing inside startups because of the of the above reasons. Time pressure makes delayed gratification difficult. Resource and team constraints as well as passion, vision and arrogance make premature optimization seem like a very smart thing at the time.

Startups have to be “all in” for a good length of time in order to be able to get quality data about the performance of a methodology. They have to practice “suspension of disbelief”, a phrase I learned from my friend Charles Teague who now runs FitNow, maker of Lose It.

If the difference between practicing a methodology and practicing an ideology is in the level of critical thinking then how does suspending disbelief fit in? Let’s call it the practice of agile ideology. The idea is that before committing to suspend disbelief, a team needs to make an explicit decision about when it will bring full-strength, data-driven critical thinking back in. The goal of the “ideological period” is to protect us from our own worst instincts. The goal of the precisely-defined condition for allowing disbelief back in is to protect us from going native. Here are some practical examples:

• Agile development practitioners recommend that inexperienced teams go through at least 2-3 full iterations before they start tuning their practice of a methodology.
• In A/B testing you can use the convergence method to get a better sense of when to discontinue a test.

One of the areas where I don’t have a good rule about when to believe and when to question is in customer development. While the model is very iterative, the amount of effort spent per iteration and the estimation of the quality of data coming back is something I need to learn more about. I’ll ask that question of Bob Dorf, the guest speaker of a free customer development event I’m putting together with General Catalyst in two weeks as part of FutureM. Bob is a long-time partner of Steve Blank, the father of customer development, and a co-author of Customer Development: The Second Decade—a dramatically-updated Four Steps to the Epiphany. This is going to be the first “under the covers” look at the latest in customer development.

I hope those of you near Boston can come to the event. Even if you can’t, please share the details with your startup friends from the main event page so that they can benefit from Bob’s perspective and the discussion.

For example, we now think about our pictures as stored on a PC or Mac, uploaded through a USB cable and protected by an online service such as Carbonite or Dropbox. We select which pictures to put in Facebook, Flickr or Picasa Web Albums. In a couple of years we’ll think about the pictures as stored primarily online, directly uploaded there by our WiFi or UWB-enabled camera and protected by a service such as Backupify (yes, we’ll still need backups).

Our computers’ will still have our documents and pictures and music downloads but these won’t be the “master” copies but serve merely as performance optimization and offline access caches for the data, in the same way you can read your email on a plane with no WiFi access using Google Gears for Gmail and Cached Exchange mode for Microsoft Outlook. Amazon’s Kindle is another good example. I read my Kindle books on my laptop, iPad, iPhone, Blackberry and, oh yeah, Kindle. All my content is there, locally cached for fast access without requiring connectivity with the latest read position automatically synchronized without me having to even think about it.

Side note: A few weeks ago Google deprecated Gears with an eye towards HTML5 offering more standard approaches for building these types of application experiences. I would expect significant extensions–going well beyond HTML5–to show up in ChromeOS.

The change will profoundly impact both the hardware and SW industry. On the hardware side, it benefits netbooks and tablet devices as well as smartphones. On the software side, it benefits third-generation SaaS players who are targeting this deployment model as they will have a noticeable performance and user experience advantage over current-generation Web apps.

I’m even more excited about fourth-generation SaaS apps whose user experience will automatically scale up and down with the capabilities of the client-side hardware and bandwidth constraints, similar to the way some gaming engines & services work today.

The shift of master data from PCs and local networks to the cloud creates significant opportunities. Get in touch if you are working in this area–I’d love to hear from you.

• My target audience is [...]. There are [...] thousands/millions of these businesses/people in the US.
• Our goal is to have [a few dozen .. a few tens of thousands] of users in the first few months after launch.

In working with startups, I hear this all the time. What I don’t hear enough of is how a company is going to select its very first customers. Unfortunately, that’s because most early stage startups don’t select their early customers. Instead, they are happy to have any customers. They are simply trying to get customers as opposed to select them. In that lies the root of many problems startups have with product/market fit and building scalable go-to-market models.

Let’s set the record straight:

All customers are not the same. Some are good, some are bad.

Therefore:

All revenue is not the same. Some is good, some is bad.

One of the worst things that can happen to a startup is dealing with and especially taking money from a bad customer. The definition of a bad customer varies based on the nature of the business you are in. Some common examples in the enterprise space include businesses who’d love to have you as a custom development shop as opposed to buy lots of product from you. In the consumer space, those can be users who have a negative product experience and then start spreading the word about it to their social network. These are cut and dry examples but there are much subtler ones.

Startups listen closely to their initial customers. That’s good, up to a point. Customers are the lens through which a startup sees the market it is going after. If the lens distorts reality in some way, especially if the company is unaware of that fact, this can lead to a series of product and business decisions with lasting and often irreversible implications for a company. Someone once said that customers own the company’s product roadmap. If a company cares about its roadmap, it better care about who its early customers are. It should therefore spend time thinking about how to select who its early customers are. That’s especially true if the company is going after a large target market.

Here’s an example of why this is the case. Say your target market is moms with kids under X years old. Let’s say there are 10 million of them. Your plan calls for having 1,000 moms use your super-cool product in the first month growing to 10,000 moms by the end of the third month. Further, let’s say that you’re doing agile development with two week iterations. In three months you’ll do six iterations collecting feedback from 0.01% to 0.1% of your ultimate target demographic. If all moms are the same and they all use your product in the same way that sampling rate would be sufficient for you to evolve the product in the right direction. Chances are that that’s not the case for your product. That creates two problems. First, you won’t have large-enough sub-samples to understand the various sub-groups within your target audience. Second, and what often hurts startups much more, is that your feedback pool will be a mishmash of what’s important to different sub-groups. If you listen and implement what the aggregate group of your customers asks for you may not be able to create an outstanding product experience for any one sub-group.

If you are building something that’s targeting a problem for a large audience (10M moms) the go-to-market question you should be asking yourself is not whether you can find some early users (1,000 out of 10,000,000). Instead you should be asking how do you select (or, to use inbound marketing terminology, make yourself discoverable by) the right 1,000 moms and what to do with any other mom that wants to use your product.

It is not often easy to figure out the profile of the best early customer for a startup. There are lots of trade-offs, for example:

• Someone who’s cheap to acquire and may not love the product vs. someone who’s expensive to acquire but will likely love your product?
• Someone you can learn from vs. someone you can get money from?
• Someone you can get money from now vs. someone you can get more money from in the future?
• Someone who has influence (Walt Mossberg) but whose negative opinion can hurt your brand and even fundraising ability?
• Someone who has a big brand but who’ll be slow to sell to, overly demanding and difficult to support or a nobody who you can make really happy?
• Someone who helps you reach critical mass (in a geography, interest community, etc.) at higher acquisition cost vs. anyone who wants to be a customer?
• Etc.

The right combination of trade-offs depends on many factors unique to any given startup. My call to action for entrepreneurs is to do the following:

1. Make a hypothesis about who your best early customers should be based on current product, roadmap and resources.
2. Validate that using your favorite techniques such as customer development
3. Develop a mechanism for determining whether a potential customer is of the right type
4. Create and validate an acquisition plan for that type of customer. Repeat 1-4 as necessary.
5. Explicitly decide how to handle potential customers who are not of the right type

The last point is very important and something startups typically find very difficult to do. Saying no to customers (revenue, etc.) is not easy. But remember: you don’t want the wrong type of customer. It can lead to problems with product/market fit, cost of sales and support, product and brand perception, capital efficiency and fundraising, etc. It can cost your team countless hours of work down the road and tons of money. Stop thinking of your customers as merely a source of benefits (validation, information, revenue) and think through the reduction in your ability to be an agile startup and real end-to-end costs associated with your ongoing commitment to deliver an outstanding product experience to them for years.

You don’t have to say yes to all potential customers. There are effective strategies for diverting and capitalizing on unwanted interest. Two that I’ve been using with the startups I’m involved with through FastIgnite are to either be honest and tell interested parties that you are not ready to have them on but you’ll let them know when it’s the right time or to set up qualification hurdles to gather data and validate fit and interest. I’ve worked with some companies that used smart automation combined with techniques from behavioral economics to not only make this a low/no-touch process but also to build up demand for their product by having non-customers market it. How’s that for turning lemons into lemonade?

What if you can’t find your ideal customers? That’s a real problem but the best solution certainly isn’t ignoring the root cause and acquiring lots of random customers. A good topic for another post…

We are calling on behalf of <dealer> to. Sorry I didn’t hear that. Please listen for instructions following this message. We are calling on behalf of <dealer> to ask a few questions about the quality of service you received. There are 5 questions and it should only take a minute of your time. Please answer yes or no to the following question when arriving for service where you graded greeted promptly. Sorry I didn’t hear that. Please say yes or no, when arriving for service where you graded greeted promptly. Sorry I didn’t hear that. Please Press 1 for Yes, or two for no. Sorry i’m having such a difficult time understanding you. Would you like to continue? Please Press 1 for Yes, or two for no. Sorry I didn’t hear that. Would you like to continue? Please Press 1 for Yes, or two for no. Sorry i’m having such a difficult time understanding you. You can contact us AT (508) ***-**** We appreciate your time and thank you for choosing <dealer> goodbye.

I wish more startups were doing cool things with voice and speech rec, especially now that services like Twilio are available..

This is a case study for the classic “How to Lie with Statistics,” in this case by accident. It’s like asserting that because, from an economic standpoint, on average, startups can’t raise money and startups fail it follows that entrepreneurs should pack up their bags and stop starting new companies and stop trying to raise money. Or that, because so few make it to pro sports and even there the injury rate is so high, high school and college students should stop trying to go pro. Or, as Freakonomics told it, drug dealers should quit the biz.

Well, there are many who feel this way but the ranks of founders, pro sports wannabes and corner dealers are growing. There are several things going on here…

Almost everyone learns about basic stats metrics such as averages and medians in the context of commonly-observed and often symmetric distributions such as the normal distribution. They make a lot of sense there. Applying them to a highly asymmetric distribution, such as iPhone app revenues or startup founder returns, without even knowing the shape of the distribution because granular data is not available, is likely to mislead the common reader. I know this because I’ve spent a couple of months studying angel returns and trying to separate reality from urban legend. More on this later.

From startups to pro sports to gambling, it is very human to pursue large statistically unlikely returns. Differently from gambling, as one invests more time in startups and sports, one hopefully gets better. And differently from sports where one gets only a couple of chances to go pro, startups don’t have this restriction. A serial entrepreneur can do many startups. In the process the entrepreneur hopefully becomes smarter, learns from past successes and mistakes and developers a bigger & better network, thereby improving the odds of success next time.

Repeat play is particularly important in games where the chances of success in any given game are very small. This includes both starting companies and joining companies as employees. If you are hot stuff, you are move likely to land a job at a hot startup.

Here is an example from angel investing based on data I’ve been looking at data recently: 68% of all angel investors lose all their money, primarily because they do too few investments. A change in portfolio size from 5 to 10 investments and 5 to 25 investments increases return at the beginning of the top quartile by 54% and 200%, respectively.  (The angel at the beginning of the top quartile has better returns than 75% of angels and worse returns than 25% of angels.) The distribution of angel returns is surely not similar to similar to iPhone apps so the example is purely illustrative.

Then there is the fact that many iPhone app developers build apps while having other jobs that provide cash, in many cases more than a typical developer salary because mobile development skills are in short supply. Therefore, we should be comparing expected returns from startup equity to expected returns from iPhone app development. It is a lot easier to start an iPhone app company than many other types of companies. Therefore, we should not be comparing the return on founding equity of a startup backed by high-quality angels and VCs. Instead, we should be comparing the differences in net cash together with the return on equity that non-founders get. I don’t have great data on this but from what I know I’d argue that, outside of lasting bubble markets, non-founders and non-execs don’t make that much on equity.

Last but not least, economics is not the whole story. Some people fall in love with code and startups. It gives them a sense of purpose and a way to express their creativity. With iPhone apps where it often takes a developer or two to build a basic app, entrepreneurs also get a lot of control and a higher likelihood of calling the shots as a CEO or an exec. I have several friends who are doing iPhone apps because they can be their own boss through a combination of consulting and self-employment. They could be founders and even execs at other startups but it’s unlikely that’ll be CEOs.

To recap, Tomi’s analysis uses good data and good reasoning but it misses the forest for the trees. This doesn’t mean everyone should pile on the mobile app bubble. My point is simply that this type of by-the-numbers analysis misses the point of why so many have gotten into mobile development.

Let me know what you think in the comments or at @simeons.