ruff

Ha, if you think that was bad, you should have been there when it was just Entourage ;).

Hmm... for all 10 digit US numbers the telcos introduce 10 DLC registrations last year that require you to register and verify your business in order to send any meaningful amount of SMS traffic. You have to provide details like a DUNs number, an EIN, and addresses that match those registrations. https://support.bandwidth.com/hc/en-us/articles/150000242224...

They haven't gotten to blocking messages that don't register but have raised the fees and fines for folks who don't register and they're able to track down.

NumberAI | Full-stack | B2C Communication & AI | Oakland, CA | Full-time | React, React-Native, Python, Kubernetes

NumberAI is a seed-stage startup, bringing AI messaging to businesses across the world. Amazingly, 80% of businesses in the US still use landline telephones. While the smartphone has changed our lives, many storefronts and offices are still communicating like it's 1999. NumberAI believes that combining our telecom prowess, machine learning, and smart product design can change the way businesses serve their customers.

We're small but growing fast as customers love our product. You are a Senior Full-Stack Engineer who will jump in and help us find, build, evaluate, and evolve solutions to our users’ needs. You’ve built, shipped, and monitored previous applications, and are looking to apply that knowledge to a new team and product. You will be directly responsible for delivering new features end-to-end, making technical decisions that keep us moving fast, and helping craft the future of our product.

Apply at: https://angel.co/numberai/jobs

I'd bet $100M on IFTTT if I had it. They've got an amazing ecosystem of often proprietary devices and services feeding event information into them.

v1 is rules by end-users—v10 intelligence by the system.

What if they could take that data and create concepts around the identity of people using those devices, where they are at certain times, what they're doing, etc. etc. Turn all that data around and broker it back to services/devices, making each of the providers that much more powerful but dependent upon IFTTT. It's super-charging the internet of things in a way that perhaps only Google (with Google Now) seems to be thinking.

Maybe different now—back then, nearly everyone only had a single Exchange account. We looked at supporting both WebDAV and EWS. The result would have introduced by confusing UX but also reduce reliability of both solutions (adds a lot of testing complexity). Instead, we did a release of Entourage with WebDAV (a horrible protocol that Exchange barely ever supported) and a free update with just EWS support (also rough initially, but much better designed and fuller-featured).

When we got to building Outlook, we decided to look forward—Cocoa and EWS only, building a strong base so that future releases could be far more capable. When I started on Entourage, the team was executing on a strategy to shove Exchange capability into a consumer-oriented app. It was shaky from the start, there were so many problems and customer complaints. I gradually learned as a PM that often a more impactful but riskier product strategy is to go big—instead of fixing 50 small issues a week at a time, fix 1 big issue that takes a year but renders the 50 irrelevant.

I was the PM who led Outlook for Mac 2011; so I know many, many of those tricks. We rebuilt the thing in Cocoa with an entirely new Exchange client codebase—it was a beast of a project done in a fairly short period of time.

For better or worse, there were a lot of edges we didn't get a chance to smooth out by the ship date though I believe we made reasonably solid trade-off calls based on the team and deadlines we had. Updating the Export feature was one of those trade-offs (it's just not a super frequent user activity); that part of Outlook leveraged code from the much-despised Microsoft Entourage. The app was far from as full-featured as some users wanted (especially Win Outlook switchers) BUT did make enough progress to avoid the backlash of other "rewrites" out there (e.g. Apple Final Cut Pro X).

Little insider history: we did a lot to try and make sure data didn't get locked-in... we really wanted a place where, even if your app crashed, you could always get the data out of the app. During development, we even had builds where the entire underlying database was exposed as XML docs (one per item in your db). We couldn't get the perf we wanted out of that system. We ended-up with Outlook 2011's database which still bites folks from time to time but has a lot more "recoverability" than previous products such as Entourage (where it users often cited being locked-out of their database).

FYI

If you drag one or more e-mail message out of Outlook for Mac, it creates .eml files. These are just RFC2822 MIME source with a file extension—almost any mail client out there can read them. If you drag an entire folder out, it creates a .mbox file. This is also a standard that many mail clients can read/import (Mail.app included).

It should make your blood boil that our government operates in such a way that companies see this as just another vector for competing against each other.

Dan Lyon's piece is pure sensationalism. Reality is likely more like: 1) there is a government affairs group inside MSFT with a $50m+ annual budget (not crazy given the DOJ impact on the company) 2) they hire a connected political machinists and give him marching orders to drum up concern over Google in DC (the same way Oracle, Novell, Netscape did against MSFT--http://www.stern.nyu.edu/networks/homeworks/Microsoft_Case.p...). 3) Guy needs a network of folks to do his deeds—he runs around DC recruiting people telling him he has a massive budget because money seems to be the most effective way to persuade people in Washington (http://www.thisamericanlife.org/radio-archives/episode/461/t...).

Meanwhile, there's a guy with a Google laptop bag doing the same thing.

Probably not something I can share (sorry); just, really, good management isn't often as much about "command as control" as it is steering a lot of smart, opinionated people who often disagree.

You're completely right on the growth aspect. If you're working somewhere with a founder and their not growing in that way while the company is, I can see nothing but headaches. The original link essentially calls this out... what you did at 5 people doesn't work at 50, which doesn't work at 150, and on. You gotta learn and adjust; as it scales up, the folks who help move beyond the Founder and into a trusted group.

You're missing the point. At some time, a company has figured out at least one way to succeed. At that time, you're going to grow extremely rapidly and take all sorts of ways the company does things, break them down into elements, and optimize to accelerate that growth. The "management team" are often the ones who drive that optimization. Someone who understands engineering is going to lead building software at scale. Someone who understands sales is going to scale out your sales. And so forth. Founders often lead this and see across all spectrums.

FWIW, I worked at MSFT and had opportunities with both Gates and Ballmer. I can absolutely ensure you management teams existed at the company. Hell, Microsoft is made of layers upon layers of management teams. A young, bright-eyed version of myself thought this was inefficient (and it was to some extent). But I got a chance once to ask Ballmer what a typical week was like for him--holy hell, managing an organization of 90k+ employees is not a challenge that many of us are made out for.

This is interesting—as someone who is part of a "management team" at a company that has grown rapidly from startup to perhaps a post-startup stage, there is some truth to this.

There's a giant void of advice out there for folks who are making this transition. It's awkward and really challenging; like hitting puberty for your company (I like to say we've got braces right now). HN and publications focus a lot on startups. Business education and literature is heavily focused on "management" in the sense of Fortune 500 like worlds (I've been in that world as well). My sense is those two appeal to much wider, paying audiences where much smaller sets of people actually make these jumps. There's very little advice/tips/thoughts about how you steer your company as you get more customers (e.g. how to manage early customers who got more attention as you were proving your product vs. later on when the cost of that attention might be a challenge), hire a lot of employees (training, compensation models, etc.), build out teams (trade-offs of various structures, ability to repeat and scale), etc. This stuff is hard and unless you're growing at such a rate you can ignore it until much later on, you have to deal with it.

Does anyone out there have a collection of posts/tidbits/advice for others who have actually managed through these transitions? The linked post talks about trial-and-error. I'd love to read about what worked and what didn't for others.

There are a number of much larger "organizations" out there that run with dispersed/non-centralized authority. Morning Star is a good example cited by HBS Review: https://archive.harvardbusiness.org/cla/web/pl/product.seam?...

BTW, if you're interested in these types of orgs... the linked article is interesting because it actually goes into some of the Pros/Cons of running your company this way. It's not written by an ideologue.

BTW, another approach is eventually tackle a vertical... perhaps you'll end-up being the #1 CRM app for small practice attorneys, dentists, accountants, etc... you can potentially carve out a niche there, give yourself more focus on whom you want to build for and what their problems are, and find venues for better addressing those markets. I know several folks who started out thinking "broad", received limited but helpful initial adoption, talked to their customers and saw patterns of the types that seemed to have the biggest unmet needs and were actively seeking new ideas/solutions. Then you start to double down.

Small thing—but not sure I'd buy a product from a company called "Dangerous Apps"

It's been a while since I've used Goldmine, ACT, or any of the more SMB focused CRM apps but it's definitely not clear why I'd choose CRM Fly vs those products. i'd emphasize simplicity and ease of use—there are a lot of folks out there who benefit from sales tracking tools who simply don't need everything out there.

Would, however, suggest things like XL exports and perhaps consider SaaS opportunities or partnerships around things like invoice printing/automation. If your approach is "simple, easy, helpful" (cause the other guys are complicated bloatware) then think how you can do this end-to-end for whomever you are designing/building for.

A very tough problem to solve: you organize by customer and you start to get requirements driven by particular customers, making your more of a custom dev shop that can't scale the business. You organize by engineering team and you become a project manager with less visibility into customer needs. You organize by Product, intersecting between projects and customers and you end-up with lots of ownership questions and gaming by PMs (strong PMs often will circumvent others to get satisfy their customer and/or project deadlines).

I've settled on the same conclusion as I've grown our team (and tried out all of these pivots along the way)... focus on the product and scaling the business out. Settle cross-ownership disputes by trying to clarify who makes the decision. Reflect regularly and adjust accordingly.

They also don't share the methodology--for example, Entourage 2008+ and Outlook for Mac both use WebKit and all HTTP requests from them don't identify them as a client. Not sure if they are lumping that under Apple Mail or not accounting for it.

Emeryville, CA (super short/BART ride from SF--No remotes)

Location Labs (http://www.locationlabs.com/jobs.php)

  * Back-end devs (Python, Java, Ruby)
  * Front-end devs (JavaScript, CSS, HTML5)
  * Mobile devs (Android, iPhone, Blackberry, BREW)
  * UX gurus (usability, designers, tech writers)

Emeryville, CA (first Bart stop from SF across the Bay)

Location Labs http://www.locationlabs.com/news/jobs/

Location-based mobile consumer and safety services. Shipping on over 100m devices in the US. Opportunities range from mobile development (iOS, Android, Blackberry), backend (Python, Ruby, Java), and frontend web devs. Other opps include Product Management, QA, and Build/Release engineers.

It's opt-in--definitely no way to get a locate without a device owner providing permission to do so. It's kind of like a Facebook app, if you're using a service that uses Veriplace to get location information, any end user can log in and modify (or deny) what information that service can access. Location data is only stored as specified by your Veriplace settings and otherwise isn't kept around.

Veriplace is a location aggregator (for details, see http://developer.sprint.com/site/global/go_to_market/aggrega...). Essentially, every carrier has a disparate location infrastructure that would require significant development and customization to integrate with. Simply too much work for most developers. Veriplace and other aggregators provide a much simpler, singular API for accessing location data across multiple carriers.

To be clear--these companies are tightly regulated and strictly watched over by both the government and the carriers. It's not these services that should be the concern, it's more so data retention policies and what not of carriers where the data originates.

Bill Atkinson remains one my idols. If only the Hypercard source would be released!

Location Labs (http://www.locationlabs.com/jobs.php)

Emeryville, CA (super short/BART ride from SF--No remotes)

Back-end devs (Python, Java, Ruby), Front-end devs (JavaScript, CSS, HTML5), Mobile devs (Android, iPhone, Blackberry, BREW), Product Managers, UX Designers

And more... Company is growing very rapidly in an incredibly exciting space.

The Pixar Story has some issues with it--largely cuts out Alvy Ray Smith and gives a lot more credit to Steve Jobs than deserved. I'd recommend reading The Pixar Touch for a balanced portrayal of the company.

For what it's worth, I got to know Alvy by running into him at various Seattle breakfast spots over the years (he's in Berkeley now). If you ever get to hear him speak, be sure to go up and talk with him. He's nothing but a welcoming, smart, and humble guy.

Don't know if it still does it but ClearContext use to provide this exact solution for Outlook. It prioritized your Inbox based people and e-mails that you haven't responded to yet.

http://www.clearcontext.com/user_guide/contacts.html

The product seems to have chased off into GTD-land, but the sort of the Inbox was really useful.

The bozo bit is starting to flip... Give the PM the benefit of doubt; I'd be direct with him about why you don't think his actions are right--tell him what you expect from him and why the way he's behaving isn't constructive. If he doesn't listen, do your job, watch your back, and communicate to your boss how this guy isn't healthy for your team.

This is a good point and something I should have made clearer. As PM, you ar first and foremost the customer advocate. Drop the ball here and you fail.

Engaging at a more technical level needs to be about ensuring focus, not meddling where you don't understand. For example, cootdinating architectural decisions does not mean designing the solutions (your senior devs do that) but it does mean infusing those discussions with customer centric decision making. The worst thing a PM can do is act like they know something without actually doing so--as others have noted, you need to listen and learn.

My experience may be a bit different; when I started, my boss was checked-out and looking for a career change. To learn the role, I got to know our developers really well (in the end, they have lots of power) and asked them what the PMs did well and didn't do well.

I'm a PM at a large, well known software company. In fact, I lead a team of PMs and have been in a PM role for several years after running a failed software startup during university and a stint as a sales and marketing guy at a solar start-up.

This article does a great job summing it-up: the PM role is about taking the vision, converting it to execution of a strong product, and facilitating a feedback loop that helps drive the vision forward.

A lot of times the PM is denigrated as an excess or waste, particularly in start-ups. It's true that a lot of PMs are taxes to their teams. But good PMs will bring a lot of clarity and absolute focus. I'm sure strong founders are also very capable of this but it's likely a matter of time and focus for those founders relative to other competing objectives.

Tips on doing PM well:

- Live. Eat. Breathe your product. I've spent years working on a product that I secretly detested but used that frustration with the product as a motivation to learn the product space inside-out and established myself into a position to remake the product what it needs to succeed (rebranding, significant technical overhaul, slash/dash legacy feature weights, etc.). Our customers are going from constant complaining to singing praises—that's hugely rewarding personally.

- Squash out all forms of inefficiency in the team. Every aspect of development that reduces your ability to deliver the best product is a concern. I'm engaged in everything from the architecture, feature prioritization and scheduling, end user usability and aesthetics, support workflows, license agreements, and key customer account discussions. I coordinated the entire team's shift to agile development practices including deciding the structure of each sub-team (our dev team is quite large and split across different countries)--as the PM for a large team you are in a unique role to see all sorts of opportunities for improvement. But be very careful--don't be shallow in identifying something as inefficient. For example, driving out prototyping time from devs reduces both their morale and creativity, two valuable resources. Another common mistake, seeing process as efficient… Creating checklists that engineers spend more time checking-off than delivering value to customers. Bad PMs excel at this.

- Software is the output of people and your ability to drive, motivate, and coordinate people is key to their ability to deliver the product. Process and schedules are mere tools for organizing people, don't let them dominate you, the team, or the product. The best PMs are really good with people and care about the team's success more so than their own because they know that a product and team's success will ultimately be good for their own career. The role often puts you in a leadership position with the team—don't be afraid to lead.

- You will constantly straddle the expectations of upper management, peer managers, and the individuals on your team. Knowing how to balance all of that and communicating appropriately to each set is a really important skill. Also, be prepared to be honest when the news isn't good--bad PMs will hide things and hope for miracles. Your job is to help people make the right decisions even if it means you get ripped apart in a couple meetings.

- The most important thing to deliver to the team is focus. Get the distractions out of the way and point the direction to the what needs to get done today. If you're nuanced, you can do this without making it feel burdensome or dictatorial. The best is building a team and process where the team can answer focus questions themselves.

Here's what day:day job entails (these will often change based on the size of the company and the scope of your influence—as mentioned, I drive a team of PMs for a software product that straddles the consumer/enterprise space:

- Meeting with key customers and getting requests/appeasing them around product direction (and knowing when to ignore them or probe deeper about what they really need vs what they are saying)

- Working with or sifting through market research about the space to try and forecast the demand for certain features

- Driving these requirements into a schedule and managing that schedule with development, often a negotiation between you, development, and management—this bullet really underestimates this as often this is what more junior PMs spend a lot of time doing

- Bubbling up engineering opportunities that need prioritization and/or could save costs and/or better align your team to future customer opportunities

- In larger orgs, coordinating across teams about aligning bigger customer bets and scenarios

- Drafting functional specs that range from whiteboard drawings to many-paged docs describing how things will work (totally depends on your ability to communicate, the team you work with, etc)

- Driving the overall look-and-feel of your product in alignment with usability, branding, and revenue concerns - Making the calls about what hits the quality bar to go in/out a version of the product

If you want a good start at understanding some aspects, see Making Things Happen by Scott Berkun (http://www.scottberkun.com/books/making-things-happen/).

This is a great point--once you've set your price, it's very hard to come up. It's a lot easier to establish value with your product/brand at a higher price and then offer an alternative, lower-priced SKU to get more volume while still using differentiation and upsell to the higher margin product. In the case of Omni, think OmniOutliner Pro vs. OmniOutliner.

It'd be interesting to see if a lot of money was left on the table when the iPhone app price rushed to $0.99 in the name of volume over long-term profit. Certainly a win for Apple in gaining end-user adoption of the store and showing that it's a viable marketplace, but I can't help but thinking value isn't being captured by price (a lot of iPhone apps cost less than a disposable, bottled soft drink).

http://blogs.msdn.com/techtalk/archive/2005/12/16/504872.asp...

One thing to consider is looking outside the CS department. When I was in school, some of the most talented hackers who were actually trying start-up ideas were students in various random majors who spent much of their time toying with ideas and technology rather than focused on classwork. Didn't make them great students but several of them went on to launch moderately successful ventures.

Seconded the suggestion of IdeaBounce. There's actually a fair amount of entrepreneurial spirit at WashU, though a lot tends to be in the biomedical area. While I wasn't a WashU student (ex-fiance was), I participated in IdeaBounce for a while and eventually networked my way into several other groups in St. Louis that were doing interesting things.

Beyond that, I had a similar experience as a student at Iowa State. Smallish town, a lot of folks focused on getting jobs, and the general creativity of the entrepreneurial groups a bit lacking. Eventually I made my way through to various programs about start-ups run by the state of Iowa and met a number of angels, early stage investors purely to meet other people doing interesting things (which landed me time doing sales at a photovoltaics company and business planning for a textbook coop idea). Really my goal was to meet a lot of people and learn a lot of things such that, when I moved out of Iowa (I'm in SF now), I felt like I made the most of the opportunity in the time I spent there.

In the end, I think if you try to be open and meet a lot of people, you'll eventually find others that share your interest and match well. Use STL as a place to hone your skills, toss ideas off people, and prepare yourself for opportunities in the future. Perhaps something will stick between now and graduation but, if it doesn't, you'll have learned a lot.