peter_mcrae

When the product marketer, product manager, and designer are the same person there is no alignment meeting.

I don't disagree on cutting these roles first, but I don't think it's a function of these roles being non-important; rather when a company stops growing these roles have less utility. Less about the role and more about the company priorities which shift when growth stalls. No one is sales is going to advocate for less marketing spend.

Agreed really good fit. I bet a large % of Segment's customers were using Twilio endpoints. Really nice combination of a data hub / last mile across multiple channels...fully expect they will continue moving up the stack towards a CRM / Marketing automation solution.

That is probably true. But, I'd also suspect that in 99% of cases some form of that data (lots of post processing) ends back in data store where all kinds of people use SQL to analyze it. Two main reasons: 1) join it with other data 2) SQL is so widely understood across functions / roles

The tech companies you identified are getting hit 1st. I expect to eventually see fallout in Fintech, Realestate, Advertising, anyone selling B2B SaaS (particularly to marketing/HR/ sales departments, SMB), etc. It will take time to feel the 2nd and 3rd order impacts. Hopefully, we bounce back quickly, but it's hard to not be a little concerned.

I’m not into celebrities nor am I a Laker fan —- really the opposite — but this has hit me more than I expected. One of the best comments I’ve seen is about how Kobe more or less achieved self actualization. He willed himself to be one of the greatest ever at his craft and was on his way to doing it again off the court while being what I can see from the outside as an amazing dad. It’s sad to see someone with so much to give the world life’s cut way short.

The people regularly reading CMO today has to be a very valuable audience -- they probably make a ton of money selling that data as anyone selling into Marketing departments would pay a lot to be able to target those folks.

Sadly, my appraisal came in "magically" at list price, so I had to put down a lot more at close. It was 3 years ago so we've done well regardless. I think you are right, I'm pretty sure the appraisal is just a guess. Most people I know had the appraisal come in way high, so maybe I got the one honest person.

In the simplest terms, Google Tag Manager (GTM) is a script you load on your site that then loads additional (arbitrary) code based on conditions (which are executed client side). In the case of something like GA, let's say you want to track a new website activity or maybe want to pass data to a new custom dimension. Without GTM, you would update your GA javascript file. With GTM, you would make the update within their interface and that new code would get injected into your site. This enables (for right or wrong) the analytics team to manage what / how data gets collected in GA.

Within GTM you have the ability to inject html, javascript, css OR in many cases they have a wizard where someone less technical can put in some info and the code is generated. You can also use conditions to determine which code should load. For example, if page URL matches "orderConfirm" then execute this. Moreover, it gives you the option of when the code should run (immediate, DOM ready, onLoad).

Aside from GA, most companies have a shit load of 3rd party scripts that run on their pages, so GTM provides a central place to manage everything.

One problem is that anyone with editor access to GTM can inject just about anything (unless you block custom scripts within GTM which has other implications) and those deployments are real-time and done directly within the GTM web interface. I'm a developer on the marketing team, so I'm a fan, but it's risky in the wrong hands.

This is a really important point. It can be really helpful to decouple analytics / tracking from the application -- especially in large companies. However you need to fully understand the security implications (don't trust vendor code!), have someone that is technically inclined using it, make it easy for the product teams to debug around it, take ownership of QA, etc.

Having a job (which provides for your children) that requires you to be at work at a certain time is poor scheduling?

Symantec – Mountain View, CA

-- Principal Front-end Engineer --

Symantec's eBusiness team is rebuilding our global stack with one that relies on modern open source technologies. We do over a billion in revenue online each year. We are seeking an experienced engineer to be a technical lead for the front-end engineering team.

You write code every day, enjoy delivering complex projects, are passionate about leadership, and looking to grow into a management role. You make others around you better and people love working with you.

Skills:

Great developer and teacher

Strong understanding of utilizing MV* for front-end applications

Experience developing, deploying, and running NodeJS applications in production

Please reach out to peter_mcrae at symantec.com.

Agreed that both presentation styles work. That said, regardless of the "strategy", the delivery needs to be clean to be seen as authoritative (unless a tremendous amount of respect as been pre-built). Imagine your CEO delivering an all-hands with 47 ums and reading from a script -- how much confidence would that instill?

Totally agree. The content is great, but the delivery is uncomfortable (both speakers). I stopped watching and just listened. Ultimately, the content is the most important thing and I appreciate the opportunity to access awesome content. If anything, I think the first lecture helped humanize the whole "start-up scene". From the outside, it seems like everyone has figured it all out, but clearly we all have areas to improve.

Lastly, given that this will be so broadly distributed, I totally get the need to be on message so it may make sense to read in this scenario.

Awesome work! Will look at replacing some hand rolled stuff internally. One gap I see with a lot of A/B testing analysis is that it only solves for conversion. While conversion is a great metric for many tests, in my experience, revenue is often the metric that matters most. Whether it's traditional eCommerce or selling tiered subscriptions, a lot of testing is geared towards 1) getting the customer to buy and 2) getting them into a more expensive product or plan. In the subscription scenario, some sort of customer life time value model is even better. I don't pretend to know all the math, but the calcs I've seen focused on revenue (AOV * conversion) need order level data (as opposed to aggregate) so it's not as easy to solve generically.

First post on HN. I'm not entirely sure how the PayPal Node vs. Java message has been packaged, but I think there is a lot of confusion. From my understanding (via blogs and conferences), Node was used to replace Java on the front-end. Meaning, the Node front-end is still calling Java + other stacks upstream -- which likely explains the performance benchmarks (the front-end wasn't the bottle neck). That said, even with similar performance benchmarks, I can see how Node might result in higher developer productivity for the front-end components of PayPal -- hence the enthusiasm they are showing. Lot's of negativity and blame on this thread, but I think it's because people are making assumptions.