Ha, if you think that was bad, you should have been there when it was just Entourage ;).
63 karma · joined February 12, 2009
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 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
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.
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.
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).
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).
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.
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.
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.
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.
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.
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.
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.
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)
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.
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.
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.
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.
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.
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.
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/).
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).
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.