spittet

Tabby is actually the name of our mascot (Tability.io). I agree that OKRs are context dependant, and you can add a lot of context in the box to get better suggestions (ex: We have an eCommerce platform selling mainly _____, and we want to double the number of returning customer).

That being said, the goal for us was to help people get a draft plan that they can tweak later. For instance, I don't know anything about PR, but I can ask the AI to generate a plan to get press and use that as a starting point.

We've also experimented with an AI that looks at past data to provide better advice, but you'd have to be in the product to see it.

I hear you. I think OKRs suffer from having a lot of literature covering the surface (benefits of OKRs, general definitions, success stories...) but not a lot of content providing a prescriptive approach.

To me it feels a bit like structuring a JS/TS app. You've got powerful tools, but it can quickly become a mess without a good structure around it.

My general recommendation: no one should have more than 7 KRs to track on a weekly basis. And an OKR plan should be a 3x4 matrix: 3 Objectives and 4 KRs/Objective.

We've tried to find some public templates but Gitlab was pretty much the only one having public OKRs[1].

[1] https://about.gitlab.com/company/okrs/

Thanks for the feedback. Part of the motivation was to remove the pain out of having to figure out what your OKRs should look like.

It won't be perfect, but usually the AI can come up with a good draft.

For developers that might be true that voice/video call is not happening often but I don't think that other business functions would share the same perspective. The ability to call, video conference and easily share images and docs is an important need for collaboration in Design, Marketing, Product Management and as a PM I often had to share screenshots back with engineers to illustrate what I'm talking about. Then, from my experience large orgs do not want to have multiple chat systems that compete with each other internally, so they'll take the one that offer more versatility while being also easy to use.

Disclaimer: I'm an ex-Atlassian (Product Manager) and my feedback is genuine, coming from experience. I'm also super happy to see my ex-co-workers getting Stride out but my opinion is not a Marketing plot. Software now requires the collaboration of many different roles, many of them who would prefer Slack/Stride over IRC.

I think you are referring to stickiness - which doesn't infer that the product is intuitive.

If you can't use a product right away without help then it is not intuitive by definition. However it doesn't mean you won't like it if taught how to extract value.

For instance it's not intuitive to deep fry a banana and then put salt on it before eating it, but I'm quite certain you will finish the plate once you try it.

Pipelines PM here. The model is a bit different, it's a pay as you go per blocks of 1,000 minutes. So if you normally use an extra 2,800 minutes per month you'll pay $30/month usually, but if for some reasons youd don't use it as much and drop to 1,500 extra minutes the next month you'll pay $20 for that month instead of $30/month every month of the year. For this reason we don't carry over minutes month to month.

Sten

Hi vegardx, I'm the lead Product Manager on Pipelines. First of all, thanks for your comment. It's still early days for us but we've had some great feedback from beta customers and making it available to all customers allows us to help a lot more teams on Bitbucket. Regarding the failed builds you can use webhooks [1] today to trigger actions after the pipeline completes and we'll work on extending this capability in the future.

Our first focus was to make a platform that can scale on demand without hard constraints on the number of containers running. We know that we have some gaps to fill but we're now moving fast and we've added several features in the past weeks (repo status, notifications, pipelines statuses everywhere).

Thanks again for your feedback. Let me know if you have any questions.

Sten

[1] https://confluence.atlassian.com/display/BITBUCKET/Notificat...

We will be experimenting different configurations during the beta to find the right fit. Some details about the resources available are published in our documentation [1] and will be updated as we move forward.

[1] https://confluence.atlassian.com/pages/viewpage.action?pageI...

Kyle, this is correct. We use containers simply to create the environment in which we'll execute the script commands in isolation. You can start with a small container and install dependencies during the run or you can prepare a bigger container with the dependencies installed already.

We don't support yet running Docker commands as part of the Pipeline [1] however it's something that we will be looking into in the future.

[1] https://confluence.atlassian.com/pages/viewpage.action?pageI...

Thanks! It's an exciting time for us and we're just getting started.

I can give some more context on our launch. Today is the start of AtlasCamp, our annual developer conference, in Barcelona. We planned the launch on that date a while ago because it's the best time for us to share this exciting news.

We've always been invested in the CI/CD market (Bamboo has been around a long time) and Pipelines was just making sense for us to do to help all Cloud teams to build great software.

Sten, Bitbucket Pipelines Product Manager

Hi,

I'm one of the Product Manager on Bitbucket Pipelines. The beta is indeed free, with a limitation on the number of minutes per user per month (starting at 300mins/user/month but that may change during the beta).

We haven't decided on the post-beta pricing yet. The beta will help us understand better how our customers are using it so that we can price it accordingly. We're leaning towards a model that scales well with the number of users on an account.

Let me know if that helps.

Thanks,

Sten Pittet